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
Jonas,
many thanks for your reply!
Am 13.06.2009 um 05:50 schrieb Jonas Maebe:
On 13 Jun 2009, at 00:55, Dr. Rolf Jansen wrote:
The problem is that the application crashes consistently after a
certain sequence of user interactions if it runs by its own.
However, the same binary does not crash, once it is attached to
gdbserver, and it does not crash even when continuing with a
couple of stress tests beyound the point at which it would have
crashed without gdbserver.
It would help so much to find the bug if the program would crash
into gdb and if gdb could show me the related source code. This
usually works quite well, for example when writing to memory at NULL.
Perhaps somebody has an idea about what type of bug might cause the
behaviour described above.
As you surmise below: probably using uninitialised and/or freed
memory.
There was a debugger for Mac OS Classic called MacsBug, that had a
setting for scrambling the memory, so that accessing released
memory would immediately result into a crash. I cannot seem to find
a similar feature in gdb. Does gdb have any settings, that I can try?
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.
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.
Regarding scrambling local variables on function entry, I believe
that recent GCC's support doing that as well, but I don't know the
command line option by heart.
For several reasons (which would make up for a story of its own), it
would surprise me, if this is problem with local variables, but I will
have a look in that, anyway.
From memwatch I know that there are more than 70000 memory
allocations from which half of it are already free'd until the crash
occurs. My program is written in objective-c and my part consist of
30000 lines of code and the frameworks that are in use are about
150000 lines, which makes this problem not a trivial one. My part and
the frameworks are compiled with complete debugging symbols, and I can
step through every single part of the whole program. So, for me it
would already be perfect if gdb/gdbserver could simply stop the
program where without gdbserver being attached it would crash.
Rolf Jansen