I am making a library that have too much code to give it here.
My problem is a segmentation fault, that Valgrind analyse as:
Jump to the invalid address stated on the next line
at 0x72612F656D6F682F: ???
at [...] (stack call)
Thanks to this question, I guess it is because I have a stack corruption somewhere.
My question is: how to find it?
I tried using GDB, but the segmentation fault appears to not be at the same place. GDB tell me it is on the first line of a function while Valgrind tell it is the call of this function that make a segmentation fault.
If the problem is repeatable, you can use technique similar to this answer to set a watchpoint on the location of return address, and have GDB stop on the instruction immediately following the one that corrupts it.
Since this is from years ago, you've probably figured out your bug. But for anyone who might stumble upon this, I would strongly encourage you to look into the "sanitizers".
If you're running Memcheck, you can probably run AddressSanitizer, which exists in both clang and gcc. AddressSanitizer can often detect stack corruption issues better than Memcheck. (Besides stack corruption, AddressSanitizer can detect many different types of addressing bugs).
However, if you scroll back in your Memcheck log, you might see Conditional jump or move depends on uninitialised value(s)
, in which case you're using an uninitialized variable, which is often harder to debug. For this, you can try MemorySanitizer (currently clang and Linux only, https://clang.llvm.org/docs/MemorySanitizer.html). In particular, look at the origin tracking options. This provides better origin tracking than Memcheck for uses of uninitialized variables. Do note, however, that MemorySanitizer is not trivial to set up, as it generally requires all external libraries to be built with (MemorySanitizer) instrumentation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With