Re: random results with the gdb testsuite

[Michael Snyder <msnyder@vmware.com>]

Denis PILAT wrote:
> 
> Michael Snyder wrote:
>> Denis PILAT wrote:
>>> Daniel Jacobowitz wrote:
>>>> On Fri, Oct 10, 2008 at 10:22:50AM +0200, Denis PILAT wrote:
>>>>
>>>>> Here is part of the log file. At a specific time  (p/f *(long long
>>>>> *)) it
>>>>> seems like the debugger hangs up, then all further test are
>>>>> UNRESOLVED.
>>>>>
>>>>> If I run this test and don't touch my keyboard, don't switch the
>>>>> current
>>>>> window, then it's 100% successful.
>>>>>
>>>>> If I'm using the console window intensively after having run this
>>>>> test,
>>>>> switching window, using keyboard,  then I get the following log where
>>>>> apparently my debugger crash, or just close.
>>>>> I can't find a way to debug that problem.
>>>>>
>>>> Normally Windows (you did say this was Windows, right?) can be
>>>> configured to pop up a dialog when a program crashes.  You can't
>>>> necessarily get into GDB from there, but you may be able to get some
>>>> kind of dump.  I think the Cygwin folks have instructions on getting
>>>> stack dumps or even core dumps from that point.
>>>>
>>> Sorry, I said window but not in the Microsoft sense. I'm using kde in a
>>> linux RHEL3.
>>> My debugger terminates, but I can't determine how, valgrind detects
>>> nothing, it's like if the process is "killed -9".
>> What happens if you run gdb by hand, and repeat each command
>> from the log?
> Everything's fine if done by hand. I get the testsuite expected results.
> Like if I run the test without doind anything else on my linux.

Ah, how frustrating.  I have occasionally run into that type
of behavior.  It can be very challenging to debug.  It implies
that the testing framework itself is perturbing the system.

Could be timing issues, could be memory locations being shifted around.

There's a load address randomization feature in modern linuxen,
have you tried disabling that?

Other than that, sticking "printfs" into the expect scripts...
;-(