3 ms·
A small aside, would be interested to hear how you tracked down the bug? Obviously after you have solved the root cause. In the embedded world, I would put a b
by yitchelle 11y ago
A small aside, would be interested to hear how you tracked down the bug? Obviously after you have solved the root cause.
In the embedded world, I would put a breakpoint on a write operation for that address. Once the breakpoint is triggered, I would inspect the trace.
- pixelp3 11y agoThis is in the embedded world, unfortunately the gdb for this platform is rather limited and watch breakpoints don't work as expected. Essentially here is what was happening: -Create C++ object -Try to point some reference to this object, but object address is suddenly 0x1 (just by doing one step in gdb) when trying to access one of it's properties. -Tried to run it with valgrind, and it works fine with valgrind, which leads me to believe it is some memory allocation issue with C++ on the heap -I modified the C++ class to have a uint64_t variable before the variable declaration. Now program works fine! I believe the issue is probably with heap corruption at some point, when something overwrites certain addresses.Having that extra unneeded 64-bit int in the heap makes it still be valid.
- yitchelle 11y ago> This is in the embedded world, unfortunately the gdb for this platform is rather limited and watch breakpoints don't work as expected. Thanks for sharing. There is nothing like a JTAG debugger with this kind of bugs. Good luck that it does not resurface later on.