[Bug threads/10046] internal-error: linux_nat_resume: Assertion `lp != NULL' failed.

["pedro at codesourcery dot com" <sourceware-bugzilla@sourceware.org>]

------- Additional Comments From pedro at codesourcery dot com  2009-04-08 19:12 -------
Subject: Re:  New: internal-error: linux_nat_resume: Assertion `lp != NULL' failed.

On Wednesday 08 April 2009 19:49:33, GNUtoo at no-log dot org wrote:
> hi,
> I've the following problem when trying to debug wesnoth:
> [New LWP 3306]

Looks like either wesnoth is using `clone' directly
instead of pthreads, or, you've got a libthread-db issue.  If the
latter, fixing up your pthreads setup will fix the issue.  See
the last points in the FAQ here: http://sourceware.org/gdb/wiki/FAQ .

> infrun: TARGET_WAITKIND_STOPPED
> infrun: prepare_to_wait

This was the new_thread_event path in
handle_inferior_event immediately resuming the
inferior.  LWP 3306 had hit a breakpoint, ...

> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x4000e56c
> infrun: context switch
> infrun: Switching context from LWP 3305 to LWP 3306
> infrun: BPSTAT_WHAT_CHECK_SHLIBS

Then it hits the breakpoint again, this time, we'll report
it.  We switched context to LWP 3306.  It was a shlib-event
breakpoint, an internal breakpoint.  It means LWP 3306 caused a
shared library load.  GDB sets a breakpoint at a magical place
to be noticied of such events, so that's your breakpoint.

> infrun: no stepping, continue
> infrun: resume (step=1, signal=0)
> infrun: prepare_to_wait
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x40011eec
> infrun: software single step trap for LWP 3306
> infrun: no stepping, continue
> infrun: resume (step=0, signal=0)
> infrun: prepare_to_wait
> [LWP 3306 exited]

Eventually, LWP 3306 exits.  

> [LWP 3305 exited]
> infrun: infwait_normal_state
> [New LWP 3297]
> infrun: TARGET_WAITKIND_STOPPED

Another LWP reports a breakpoint hit.  Again, we enter the new_thread_event path
in handle_inferior_event, which does this:

 if (ecs->new_thread_event)
    {
(...)
      target_resume (RESUME_ALL, 0, TARGET_SIGNAL_0);
      prepare_to_wait (ecs);
      return;
    }

Remember that inferior_ptid is still pointing at LWP 3306, an LWP
that has exited already.  RESUME_ALL is minus_one_ptid.

> /home/embedded/oetmp_openmoko/work/armv4t-angstrom-linux-gnueabi/gdb-6.8-r3/gdb-6.8/gdb/linux-nat.c:1152:
> internal-error: linux_nat_resume: Assertion `lp != NULL' failed.

So, linux_nat_resume asserts, because it does:

static void
linux_nat_resume (ptid_t ptid, int step, enum target_signal signo)
{
  /* If PID is -1, it's the current inferior that should be
     handled specially.  */
  if (PIDGET (ptid) == -1)  
    ptid = inferior_ptid;         <<<<<<< here, ptid is LWP 3306.

  lp = find_lwp_pid (ptid);
  gdb_assert (lp != NULL);  <<<<<< right, LWP 3306 is gone by now...

> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n)
> 
> the strange thing is that I didnt play with gdb...I just ran wesnoth with:
> gdb wesnoth
> run -f -r 480x640
> and I've waited until it crashes...I didn't add breakpoints etc...like in this
> bugreport:
> http://sourceware.org/ml/gdb/2008-08/msg00163.html

Right, GDB added them for you :-)

Probably the fix is to make new_thread_event context-switch to the
new thread before resuming.  It also beats me why new_thread_event
needs to resume the thread, thus making the inferior hit the same
breakpoint (or any other signal) twice.



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10046

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.