My code is run and compiled on a 64bit linux, (a redhat install) I code/compile/run on Fedora 64 bit as well (21 or 23 depending what computer I use with a newer version of GCC and kernel)
What happens: On the server running the code, there is a memory corruption bug, that I can trigger everytime doing the same thing. When I finally could detect what triggered it I was quite happy, as I could at last solve it. Problem is I cannot replicate it locally, and more troublesome, Valgrind detect nothing at all as well. And that puzzles me. (at first I thought it could be me that screwed something by relying on 64 bit value limitation)
What annoys me is that I only have the command line on the server, and having to learn gdb in command line for just this one bug is not exactly what I want to do (I code in Eclipse, and having the capacity to look at the memory in one windows while clicking to do step by step debug and see the line and all variable at hand has quite spoiled me)
If someone is well versed in GDB the only thing I would need to know to debug is how to monitor a specific value that should not be changed (it is a static array initialied at boot) the bug always corrupt memory in this place (and others but this one will not crash anything) so I would know wich line of code did it so I can fix it. Again in Eclipse, it is as simple as putting an observer on a variable to know when it changes. But that is done in a single click :) (yeah I am taht spoiled)
If you can't figure it out with GDB, I'd recommend recompiling everything with -fsanitize=address instead and look at the stack dump from that. That should tell you the instant the out of bounds memory gets written to. You can use the addr2line program on the command line to dump out the line numbers of the code.
Valgrind not liking the sanitizing adress stuff , I was actually compiling locally for a long time without the sanitizing stuff.
Funny thing though, is I do not understand why Valgrind did not complain that I was overwriting a static string…(reminded me to change a variable name, MAX_INPUT_LENGTH is way to close to MAX_STRING_LENGTH when you read code:) )
Lesson learned, the sanitizing compile option do not do the same job than valgrind. Better use both.