This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]