This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug threads/10046] internal-error: linux_nat_resume: Assertion `lp != NULL' failed.
- From: "pedro at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: 8 Apr 2009 19:12:06 -0000
- Subject: [Bug threads/10046] internal-error: linux_nat_resume: Assertion `lp != NULL' failed.
- References: <20090408184931.10046.GNUtoo@no-log.org>
- Reply-to: sourceware-bugzilla at sourceware dot 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.