From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17349 invoked by alias); 8 Apr 2009 19:12:07 -0000 Received: (qmail 17329 invoked by alias); 8 Apr 2009 19:12:06 -0000 Date: Wed, 08 Apr 2009 19:12:00 -0000 Message-ID: <20090408191206.17326.qmail@sourceware.org> From: "pedro at codesourcery dot com" To: gdb-prs@sourceware.org In-Reply-To: <20090408184931.10046.GNUtoo@no-log.org> References: <20090408184931.10046.GNUtoo@no-log.org> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug threads/10046] internal-error: linux_nat_resume: Assertion `lp != NULL' failed. X-Bugzilla-Reason: CC Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2009-q2/txt/msg00032.txt.bz2 ------- 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.