Re: program does not crash when attached to gdbserver

[Jonas Maebe <jonas.maebe@elis.ugent.be>]

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