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
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.
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.
Pointers are difficult to understand when they're represented only as text.
DebugPal visualizes the simulated memory state with:
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.
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.
DebugPal deliberately doesn't reveal everything immediately.
The guidance is split into three levels:
What does this pointer contain right now?
Is the memory address you're about to dereference guaranteed to contain a valid object?
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.
Low-level memory concepts can feel extremely abstract.
So DebugPal also explains them using everyday situations.
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.
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.
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.
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.
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:
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.
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:
free()
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.
I included four common problems that map closely to what students encounter while learning C/C++:
head->next->next
without safely checking whether the required nodes exist.
Returning or using the address of memory whose lifetime has already ended.
Allocating dynamic memory without correctly freeing the allocated blocks.
An off-by-one loop accessing an array outside its valid bounds.
Each preset is designed to demonstrate a different memory-safety concept.
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.
The project is intentionally lightweight.
No heavy framework or build pipeline is required.
The repository can be opened directly in a browser.
A built-in heuristic analysis engine handles common pointer/memory patterns when local AI isn't available.
DebugPal can generate a Markdown debugging report containing:
That turns a debugging session into something the student can keep as study notes.
For this particular use case, local AI has some advantages.
Student code can stay on the student's machine instead of being sent to a third-party cloud service.
A student shouldn't need an expensive subscription just to understand a segmentation fault in a lab assignment.
The tool can be used even when internet connectivity is poor.
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.
👉 https://debug-pal.vercel.app/
👉 https://github.com/ahanghosh77/debug-pal
The easiest way to try the application:
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.
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.
There are several things I'd like to improve after the challenge:
For now, though:
Rohan has stopped being scared of Segmentation fault.
And that's a pretty good first version.
HTML · CSS · JavaScript · Ollama · Open-weight AI · C/C++ debugging concepts
MIT
Built with ❤️ for Hacktoberfest 2026.