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

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

[GNUtoo at no-log dot org]

hi,
I've the following problem when trying to debug wesnoth:
[New LWP 3306]
infrun: TARGET_WAITKIND_STOPPED
infrun: prepare_to_wait
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
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]
[LWP 3305 exited]
infrun: infwait_normal_state
[New LWP 3297]
infrun: TARGET_WAITKIND_STOPPED
/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.
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

-- 
           Summary: internal-error: linux_nat_resume: Assertion `lp != NULL'
                    failed.
           Product: gdb
           Version: 6.8
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: threads
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: GNUtoo at no-log dot org
                CC: gdb-prs at sourceware dot org


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.

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

[GNUtoo at no-log dot org]

------- Additional Comments From GNUtoo at no-log dot org  2009-04-08 18:54 -------
mmm...GNU gdb 6.7.1 works(pass wesnoth's tutorial fine) on my desktop computer...



-- 


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.

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

[pedro at codesourcery dot com]

------- 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.

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

[pedro at codesourcery dot com]

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

On Wednesday 08 April 2009 19:54:18, GNUtoo at no-log dot org wrote:

> ------- Additional Comments From GNUtoo at no-log dot org  2009-04-08 18:54 -------
> mmm...GNU gdb 6.7.1 works(pass wesnoth's tutorial fine) on my desktop computer...

>From your paste on IRC:

$ gdb wesnoth
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run -w 
Starting program: /usr/games/bin/wesnoth -w
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb74606e0 (LWP 27905)]
[New Thread 0xb745fb90 (LWP 27908)]
Battle for Wesnoth v1.6
Started on Wed Apr  8 20:52:21 2009

So on your i686 machine, thread debugging was enabled, while on
native arm GDB it wasn't.  If you fix that, you won't trip on the
GDB bug on arm.



-- 


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.

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

[chenmin83 at msn dot com]

------- Additional Comments From chenmin83 at msn dot com  2010-03-23 07:15 -------
I think you used a stripped "libpthread" library.

I met the same problem as yours on a mips-based embedded system.
I tried to use an unstripped "libpthread" library, and the problem gone.

-- 


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.

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

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-03-23 20:23 -------
On Tuesday 23 March 2010 07:15:50, chenmin83 at msn dot com wrote:

> I think you used a stripped "libpthread" library.

Yes, it must have been something like that, as discussed in comment #2.

In any case, the crash in question was fixed in 7.0, the way suggested
in comment #2:

2009-06-29  Pedro Alves  <pedro@codesourcery.com>

        * infrun.c (handle_inferior_event): Context switch to the new
        thread when resuming for a new_thread_event.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|6.8                         |7.0


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.