DebugPal AI: An Offline-First Visual Socratic Pointer & Memory Tutor Built for my Classmate

Abhishek Jha — Sun, 04 Oct 2026 16:37:31 +0000

I Built an AI Debugging Tutor for My Friend Who Was Terrified of Segmentation Faults

I didn't build DebugPal AI because I wanted to make another coding chatbot.

I built it because my friend Rohan kept getting Segmentation fault (core dumped) in our Data Structures lab—and every time an AI fixed his code, he understood the bug a little less.

So I built him something different.

DebugPal AI is a visual, Socratic C/C++ debugging tutor that helps students understand why pointer and memory bugs happen instead of simply handing them corrected code.

🔗 Live Demo: https://debug-pal.vercel.app/

🔗 GitHub: https://github.com/ahanghosh77/debug-pal

🧑‍💻 The Friend I Built It For

Rohan is my classmate and lab partner.

We're working through university Data Structures labs where we use C and C++, including pointers, linked lists, dynamic memory allocation, and manual memory management.

For someone coming from a higher-level language such as Python, the hardest part isn't always writing the algorithm.

It's understanding what is actually happening in memory.

Rohan's recurring enemy was:

Segmentation fault (core dumped)

The compiler would tell him that the program crashed.

But it didn't give him the mental model he needed to understand why.

And when he asked cloud AI tools for help, the usual experience was:

"Here's the corrected code."

The code worked.

The understanding didn't.

That was especially frustrating because our university exams aren't just about getting a program to run. We also have to explain the concepts on paper.

So I wanted to build something that would make him think through the bug instead of simply copying the fix.

🧠 Meet DebugPal AI

DebugPal AI takes a C/C++ memory bug and turns it into a visual debugging lesson.

Instead of:

Your program crashed.
Here is the corrected code.

the experience is closer to:

What does this pointer currently contain?

        ↓

Where is that address pointing?

        ↓

Is that memory actually valid?

        ↓

What invariant did your program violate?

        ↓

Now... how would you fix it?

The goal is to create the "Ohhh, that's why!" moment.

🥞 1. Visual Memory Map

Pointers are difficult to understand when they're represented only as text.

DebugPal visualizes the simulated memory state with:

Call Stack frames
Stack variables
Heap allocations
Hex-style memory addresses
Pointer targets
Invalid memory destinations
Dangerous memory blocks

For example, instead of simply seeing:

head->next->next

the student can see the pointer chain and where the final arrow ends up.

When the destination is invalid, DebugPal makes the crash point visually obvious.

This is particularly useful for beginners who have learned the syntax of pointers but haven't yet developed a mental model of memory.

🎯 2. It Teaches the Invariant Behind the Crash

A segmentation fault is only the symptom.

The more important question is:

What rule did my program violate?

DebugPal tries to make that rule explicit.

For example:

head
  ↓
node
  ↓
NULL

and then:

head->next->next

Instead of immediately revealing the corrected code, DebugPal asks the student to reason about the next pointer and whether the next dereference is valid.

This turns debugging into a small reasoning exercise.

🤔 3. Three Levels of Socratic Guidance

DebugPal deliberately doesn't reveal everything immediately.

The guidance is split into three levels:

Level 1 — Observation

What does this pointer contain right now?

Level 2 — Invariant Check

Is the memory address you're about to dereference guaranteed to contain a valid object?

Level 3 — Root Cause

What exact operation caused the invalid memory access?

Only after thinking through the first two stages does the student get the root-cause explanation.

The idea is simple:

Don't remove the student's debugging problem. Teach them how to debug it.

💡 4. Everyday Mental Models

Low-level memory concepts can feel extremely abstract.

So DebugPal also explains them using everyday situations.

For example:

Dangling pointer

Imagine checking out of a hotel but continuing to use the room key.

The key still exists.

The room doesn't belong to you anymore.

That's roughly the mental model of a dangling pointer.

Memory leak

Imagine borrowing books from a library and never returning them.

You may still be able to use the books, but the library's available resources keep shrinking.

That's the intuition behind a memory leak.

NULL dereference

You're following an address to find a destination, but the address effectively says:

There is nothing here.

Then your program tries to use it anyway.

🛡️ 5. From Bug → Safe Code

DebugPal also provides a defensive code view.

Instead of only showing:

❌ This is wrong.

it shows the vulnerable version and a safer version side by side, followed by a checklist of the programming rule involved.

The objective is to connect:

bug → memory state → violated invariant → defensive programming practice

rather than treating each compiler error as an isolated problem.

🤖 Why Open-Weight AI?

This is the part of the project that mattered especially for this Hacktoberfest challenge.

The challenge asks participants to build something with open-source/open-weight AI at its core, including local inference with open-weight models.

DebugPal is designed around that idea.

For custom C/C++ code, the application can connect directly to a locally running Ollama instance.

The browser sends the code to the local Ollama API and asks the selected open-weight model to return a structured debugging analysis.

The model is instructed to produce:

Bug classification
Crash location
Stack state
Heap state
Pointer relationships
Execution timeline
Three Socratic hints
An everyday analogy
Before/after defensive code
A debugging checklist

The response is structured as JSON so the frontend can turn the model's reasoning into the visual debugging interface.

The relevant implementation is in app.js, where DebugPal calls the local Ollama /api/generate endpoint and requests a fixed JSON schema.

📴 And What Happens Without AI?

This was important because Rohan is a student.

University Wi-Fi isn't always reliable.

So DebugPal doesn't completely fall apart when Ollama isn't available.

It has a built-in heuristic fallback that can still identify common patterns such as:

Pointer dereferencing
Missing free()
Array-loop problems
Common linked-list mistakes

The application therefore has two modes:

             C/C++ Code
                  │
                  ▼
        ┌──────────────────┐
        │  Local Ollama AI  │
        │ Open-weight model │
        └────────┬─────────┘
                 │
                 │ unavailable?
                 ▼
        ┌──────────────────┐
        │ Heuristic Engine │
        └────────┬─────────┘
                 │
                 ▼
       Visual Debugging Lesson

That architecture means the student can still use the core learning experience without depending on a remote AI server.

🧪 Built-in Lab Traps

I included four common problems that map closely to what students encounter while learning C/C++:

1. Linked List Segmentation Fault

head->next->next

without safely checking whether the required nodes exist.

2. Dangling Pointer

Returning or using the address of memory whose lifetime has already ended.

3. Dynamic 2D Matrix Memory Leak

Allocating dynamic memory without correctly freeing the allocated blocks.

4. Buffer Overflow

An off-by-one loop accessing an array outside its valid bounds.

Each preset is designed to demonstrate a different memory-safety concept.

👨‍🤝‍👨 What Happened When I Gave It to Rohan?

This was the most important part of the project.

I didn't just build the website and call it "built for a friend."

I actually handed it to Rohan in our hostel study room while we were preparing for our Data Structures lab evaluation.

He tried the linked-list segmentation fault example.

His reaction was:

"During our linked list assignment, I kept getting segfaults because I was chaining head->next->next without verifying if the list had fewer than 3 nodes. Cloud AI just gave me the corrected code without explaining why my logic failed."

Then he saw the memory visualization:

"When DebugPal drew the Stack and Heap map and showed the arrow pointing into 0x00000000 [Unmapped Page 0], it instantly clicked why the CPU crashed."

And the part I cared about most:

"The Socratic hints made me think about the loop condition instead of guessing."

He has already bookmarked DebugPal on his laptop for our upcoming evaluations.

That's probably the best validation I could have asked for.

🏗️ How I Built It

The project is intentionally lightweight.

Frontend

HTML5
CSS3
Vanilla JavaScript

No heavy framework or build pipeline is required.

The repository can be opened directly in a browser.

AI Layer

Local Ollama inference
Open-weight model support
Structured JSON output
Socratic prompt architecture

Offline Fallback

A built-in heuristic analysis engine handles common pointer/memory patterns when local AI isn't available.

Export

DebugPal can generate a Markdown debugging report containing:

Bug classification
Pointer execution timeline
Memory explanation
Everyday analogy
Safe code
Debugging checklist

That turns a debugging session into something the student can keep as study notes.

🔐 Why Local AI Makes Sense for This

For this particular use case, local AI has some advantages.

Privacy

Student code can stay on the student's machine instead of being sent to a third-party cloud service.

Cost

A student shouldn't need an expensive subscription just to understand a segmentation fault in a lab assignment.

Reliability

The tool can be used even when internet connectivity is poor.

Control

Because the model is open-weight and runs locally, students can experiment with different models and prompts instead of being locked into a single cloud provider.

That's the part of open innovation I wanted to explore with this project.

🎮 Try It Yourself

Live Demo

👉 https://debug-pal.vercel.app/

GitHub

👉 https://github.com/ahanghosh77/debug-pal

The easiest way to try the application:

Open the website.
Select a bug preset.
Click Inspect Memory & Debug.
Explore the memory layout.
Reveal the three Socratic hints one at a time.
Read the everyday analogy.
Compare the vulnerable and defensive code.
Export the debugging report if you want to keep it as notes.

If you have Ollama running locally, you can also configure the local model from the application's model settings and analyze custom C/C++ code.

🎯 Why I Think This Fits "Build for a Friend"

The challenge wasn't just:

"Build an AI application."

It was:

Build something for a real person.

Rohan had a very specific problem.

He wasn't asking for another coding assistant.

He needed someone—or something—that would sit beside him and explain:

"Stop. Look at what your pointer is actually doing."

That's what I tried to build.

DebugPal AI is basically a visual teaching assistant for the moment when your C program crashes at 1 AM and you have no idea why.

And if it helps Rohan walk into our next Data Structures lab a little less afraid of pointers, then the project has already done what I wanted it to do.

🚀 What's Next?

There are several things I'd like to improve after the challenge:

More C/C++ memory bug patterns
Better parsing of arbitrary C/C++ programs
More accurate memory-layout simulation
Step-by-step pointer execution
More local model options
Interactive linked-list and tree visualizations
Sanitizer integration
A small collection of university-style debugging exercises

For now, though:

Rohan has stopped being scared of Segmentation fault.

And that's a pretty good first version.

🛠️ Built With

HTML · CSS · JavaScript · Ollama · Open-weight AI · C/C++ debugging concepts

📜 License

MIT

Built with ❤️ for Hacktoberfest 2026.

DEV Community: Abhishek Jha