Problem with some code I'm writing

[hushed bronze]

Okay, so I'm newish to C, and I've been trying to learn by basically breaking stuff.

I'm developing on a Proxmark3 Easy, and I wanted to see if I could replace the Memory manager it uses. I got it all to compile, but I'm running into an issue with some of the new code and I have no clue how to try and fix it.

This is the repo in question: https://github.com/jlitewski/proxmark3/blob/nxtgen-palloc/armsrc/palloc.c

Attached is the local version of the code I'm working on.

So, the issue: Calling palloc_status() crashes the Proxmark3. It correctly displays the MEM_USABLE and free memory, and outputs that the heap isn't null. It goes into the count_blocks(pBlock* ptr) function, and prints that the heap and ptr are not null. As soon as ptr->next is called, it crashes.

What I gathered so far is there's possibly a problem with how the pointers are set up in palloc_init(). In the attached code, it gets to line 407 and it crashes there. I know the code on that line is weird, I've been throwing when I know at it to get it to work. All the structs are packed (since that was one of the issues I was having), and I'm on my wits end of trying to figure out why it's not working when ptr->next is invoked.

[proper whale]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

[worn flare]

I know nothing about embedded, but I'm going to take a guess by saying that the C compiler you are using to compile code for it (maybe it's just gcc/clang, idk) also supports these compilation flags. They have caught 95% of my errors the past 2 years programming C, so there's a good chance they can catch something for you too. If you want details on them, feel free to ask (or google). The fsanitize flags are able to even catch many runtime bugs:
-Wall -Wextra -Wpedantic -Werror -fsanitize=address,undefined -g

[hushed bronze]

it's compiling with gcc, I'll double check the flags

[hushed bronze]

So I did those, and it found nothing. Thank you though @worn flare, I did find a few other things that it did find in the client code

[proper whale]

@hushed bronze Has your question been resolved? If so, type !solved :)

[hushed bronze]

My guess right now is there's something wrong with the way I'm doing a linked list. Like the next pointer is corrupted or something. I just can't see it

[hushed bronze]

So in doing more debugging, it is something to do with specifically pBlock

[worn flare]

Are you debugging with something like gdb or lldb? Cause if not, definitely try that, if that's possible with embedded

[hushed bronze]

I'm currently flying blind since I don't have a jtag debugger. I've just been putting debugging prints and going through the code line by line

[worn flare]

In case you're not, do keep using -Wall -Wextra -Wpedantic -Werror -fsanitize=address,undefined -g btw, just in case you might introduce any other bugs while trying to fix your current one (and it's just good to keep on in general)

So I presume you can't just use gdb/lldb?

[hushed bronze]

I'm not sure if that would work on the device side

Apparently gdbserver is a thing

[hushed bronze]

So I figured it out

in my code, I was calculating the RAM area with (_stack_start - __bss_end__) and setting the start of the heap there, which is the BOTTOM of the RAM addresses. Setting the stack to __bss_start__ fixed the issue.

!solved