This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: program does not crash when attached to gdbserver
On 13 Jun 2009, at 15:53, Dr. Rolf Jansen wrote:
Am 13.06.2009 um 05:50 schrieb Jonas Maebe:
In general, this is a feature of the compiler and/or run time,
rather than of the debugger (the debugger cannot know how the
memory manager of your run time works, so unless you exclusively
use OS or OS-supplied library functions, it cannot scramble
anything).
I can understand this, and as a matter of fact I would have expected
that the debugger does not interact with the memory management, my
problem is that it acts somehow on mm and the runtime. It would
already be of help for me if somebody could point me to some
possible areas of interaction, which could make up for the above
mentioned different behaviour of running the same binary with and
without gdbserver being attached.
I was only pointing out why gdb does not include memory scrambling
functionality similar to macsbug.
It is true that running a program under a debugger sometimes changes
its behaviour, particularly when uninitialised memory is involved.
Such problems are often called "heisenbugs".
E.g., in case of the Free Pascal Compiler, there are the -gttt
(scramble all local variables on function entry) and -gh (use the
heaptrc unit, which, a.o., scrambles all freed memory) options.
For GCC, you can have a look which of these work on your target
platform: http://en.wikipedia.org/wiki/Memory_debugger
I experimented a bit with memwatch, to no more avail than finding
some freeing-NULL occasions. I would not have bothered you with my
case, if I would still have own ideas to try. Anyway, I will have a
look to the other options mentioned at the wiki page.
At least some of those should have options to fill freed and allocated
memory with random data. You may also want to try this one: http://support.microsoft.com/kb/286470
Jonas