This is the mail archive of the gdb-patches@sources.redhat.com 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: [RFA/testsuite] attach.exp: Add small delay in busy loop...


Daniel Jacobowitz wrote:
On Tue, Nov 18, 2003 at 04:26:07PM -0800, Michael Snyder wrote:

Joel Brobecker wrote:

Hello,

The attach.exp sometimes fails on certain platforms (eg mips-irix),
and causes an attach process to be left behind. Since it is doing a busy
loop, this runaway process left behind consumes 99.9% of the CPU,
and considerably slows down the execution of the rest of the testsuite.

I suggest the following change to add a small delay at each iteration
of the busy loop. I had to make some adjustments to attach.exp:

a. Line number 19 became line 32.
   Just like Elena recently upgraded a test to avoid hard-coded
   line number, we should probably clean this up, someday. This can
   be a separate patch, however.

b. The program was attached to while inside the busy loop, so the
   test was expecting the debugger to report that the inferior was
   inside function main() after the attach command was performed.
   This is no longer the case, since the inferior is most likely
   inside a system call, doing the delay. I felt that it was not
   a necessity to checke where the debugger thought the inferior
   was stopped, so removed that part of the expected output. What
   I can do is add an extra test that does a backtrace and verifies
   that it contains a frame for function main().

2003-11-18 J. Brobecker <brobecker@gnat.com>

      * gdb.base/attach.c: Add small delay in busy loop.
      * gdb.base/attach.exp: Make some associated adjustments.

OK to apply?

Seems to work on Linux. I'd sure like to see that backtrace test, though, to confirm that we are able to build a meaningful machine state after we attach.


Seems reasonable to me.  Warning: this will be yet another place we
backtrace from syscalls, and sometimes we just can't do that.  We
already have a couple of configurations where GDB can't reasonably be
expected to backtrace out of nanosleep.

Well, we could run to a known breakpoint and then backtrace -- but that wouldn't test the state immediately after attach. Can you think of a good test for a valid state, other than a backtrace?



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