public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* Re: threads/2383: internal-error: linux_nat_wait: Assertion `iterate_over_lwps (running_callback, NULL)' failed.
@ 2008-03-01 13:48 Atsushi Nemoto
0 siblings, 0 replies; 6+ messages in thread
From: Atsushi Nemoto @ 2008-03-01 13:48 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR threads/2383; it has been noted by GNATS.
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
To: drow@false.org
Cc: gdb-gnats@sourceware.org
Subject: Re: threads/2383: internal-error: linux_nat_wait: Assertion
`iterate_over_lwps (running_callback, NULL)' failed.
Date: Sat, 01 Mar 2008 22:46:42 +0900 (JST)
On Fri, 29 Feb 2008 11:50:18 -0500, Daniel Jacobowitz <drow@false.org> wrote:
> So you've single-stepped a thread until its exit, while it was the
> only thread running. Is that correct?
Yes.
> It seems like we ought to inform the user when this happens, not
> suddenly run somewhere else.
Hmm... Thank you, it might be better. But how to do that exactly?
---
Atsushi Nemoto
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: threads/2383: internal-error: linux_nat_wait: Assertion `iterate_over_lwps (running_callback, NULL)' failed.
@ 2008-03-01 14:58 Daniel Jacobowitz
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2008-03-01 14:58 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR threads/2383; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@false.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: gdb-gnats@sourceware.org
Subject: Re: threads/2383: internal-error: linux_nat_wait: Assertion
`iterate_over_lwps (running_callback, NULL)' failed.
Date: Sat, 1 Mar 2008 09:49:05 -0500
On Sat, Mar 01, 2008 at 10:46:42PM +0900, Atsushi Nemoto wrote:
> > It seems like we ought to inform the user when this happens, not
> > suddenly run somewhere else.
>
> Hmm... Thank you, it might be better. But how to do that exactly?
I don't know. I suppose it could be a new
TARGET_WAITKIND_THREAD_EXIT...
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: threads/2383: internal-error: linux_nat_wait: Assertion `iterate_over_lwps (running_callback, NULL)' failed.
@ 2008-02-29 16:58 Daniel Jacobowitz
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2008-02-29 16:58 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR threads/2383; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@false.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: gdb-gnats@sourceware.org
Subject: Re: threads/2383: internal-error: linux_nat_wait: Assertion
`iterate_over_lwps (running_callback, NULL)' failed.
Date: Fri, 29 Feb 2008 11:50:18 -0500
On Fri, Feb 29, 2008 at 04:28:01PM -0000, Atsushi Nemoto wrote:
> At that point, it seems gdb assume other threads are resumed, but this
> assumption is not true with scheduler-locking.
>
> With this patch, I can avoid the internal error. Is this reasonable?
>
> --- gdb-6.7.50.20080222/gdb/linux-nat.c 2008-01-30 07:47:20.000000000 +0900
> +++ gdb/gdb/linux-nat.c 2008-03-01 01:10:57.000000000 +0900
> @@ -2138,6 +2138,9 @@ retry:
> ignored. */
> if (num_lwps > 0)
> {
> + /* If lwps were stopped (by schedlock), resume them. */
> + if (!iterate_over_lwps (running_callback, NULL))
> + iterate_over_lwps (resume_callback, NULL);
> /* Make sure there is at least one thread running. */
> gdb_assert (iterate_over_lwps (running_callback, NULL));
>
So you've single-stepped a thread until its exit, while it was the
only thread running. Is that correct?
It seems like we ought to inform the user when this happens, not
suddenly run somewhere else.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: threads/2383: internal-error: linux_nat_wait: Assertion `iterate_over_lwps (running_callback, NULL)' failed.
@ 2008-02-29 16:28 Atsushi Nemoto
0 siblings, 0 replies; 6+ messages in thread
From: Atsushi Nemoto @ 2008-02-29 16:28 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR threads/2383; it has been noted by GNATS.
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
To: gdb-gnats@sources.redhat.com, nobody@sources.redhat.com
Cc:
Subject: Re: threads/2383: internal-error: linux_nat_wait: Assertion
`iterate_over_lwps (running_callback, NULL)' failed.
Date: Sat, 01 Mar 2008 01:23:06 +0900 (JST)
I confirmed this problem is still in gdb-6.7.50.20080222.
At that point, it seems gdb assume other threads are resumed, but this
assumption is not true with scheduler-locking.
With this patch, I can avoid the internal error. Is this reasonable?
--- gdb-6.7.50.20080222/gdb/linux-nat.c 2008-01-30 07:47:20.000000000 +0900
+++ gdb/gdb/linux-nat.c 2008-03-01 01:10:57.000000000 +0900
@@ -2138,6 +2138,9 @@ retry:
ignored. */
if (num_lwps > 0)
{
+ /* If lwps were stopped (by schedlock), resume them. */
+ if (!iterate_over_lwps (running_callback, NULL))
+ iterate_over_lwps (resume_callback, NULL);
/* Make sure there is at least one thread running. */
gdb_assert (iterate_over_lwps (running_callback, NULL));
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: threads/2383: internal-error: linux_nat_wait: Assertion `iterate_over_lwps (running_callback, NULL)' failed.
@ 2008-01-26 15:48 Atsushi Nemoto
0 siblings, 0 replies; 6+ messages in thread
From: Atsushi Nemoto @ 2008-01-26 15:48 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR threads/2383; it has been noted by GNATS.
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
To: gdb-gnats@sources.redhat.com, nobody@sources.redhat.com
Cc:
Subject: Re: threads/2383: internal-error: linux_nat_wait: Assertion
`iterate_over_lwps (running_callback, NULL)' failed.
Date: Sun, 27 Jan 2008 00:45:54 +0900 (JST)
I did some more debugging with gdb-6.7.50.20080126.
--- gdb session log begin ---
(gdb) break func
Breakpoint 1 at 0x8048417: file foo.c, line 5.
(gdb) run
Starting program: /work/rpms/foo
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 0xb7da96c0 (LWP 17440)]
[New Thread 0xb7da8bb0 (LWP 17443)]
[Switching to Thread 0xb7da8bb0 (LWP 17443)]
Breakpoint 1, func (arg=0x0) at foo.c:5
5 return NULL;
(gdb) set scheduler-locking step
(gdb) s
6 }
(gdb) s
0xb7ee1240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
(gdb) s
Single stepping until exit from function start_thread,
which has no line number information.
[Thread 0xb7da8bb0 (LWP 17443) exited]
../../gdb-6.7.50.20080126/gdb/linux-nat.c:2142: internal-error: linux_nat_wait: Assertion `iterate_over_lwps (running_callback, NULL)' failed.
--- gdb session log end ---
I use another gdb to debug the gdb. At the linux-nat.c:2142, lwp_list
only have one entry (lwp 17440, main thread) with stopped=1,
resumed=0, status=0. So running_callback() returns NULL.
Breakpoint 1, linux_nat_wait (ptid={pid = -1, lwp = 0, tid = 0},
ourstatus=0xbfbb9694) at ../../gdb-6.7.50.20080126/gdb/linux-nat.c:2142
2142 gdb_assert (iterate_over_lwps (running_callback, NULL));
(gdb) p num_lwps
$1 = 1
(gdb) p *lwp_list
$2 = {ptid = {pid = 17440, lwp = 17440, tid = 0}, cloned = 0, signalled = 0,
stopped = 1, resumed = 0, status = 0, step = 0, siginfo = {si_signo = 0,
si_errno = 0, si_code = 0, _sifields = {_pad = {0 <repeats 29 times>},
_kill = {si_pid = 0, si_uid = 0}, _timer = {si_tid = 0, si_overrun = 0,
si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _rt = {si_pid = 0,
si_uid = 0, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _sigchld = {
si_pid = 0, si_uid = 0, si_status = 0, si_utime = 0, si_stime = 0},
_sigfault = {si_addr = 0x0}, _sigpoll = {si_band = 0, si_fd = 0}}},
waitstatus = {kind = TARGET_WAITKIND_IGNORE, value = {integer = 17443,
sig = 17443, related_pid = 17443,
execd_pathname = 0x4423 <Address 0x4423 out of bounds>,
syscall_id = 17443}}, next = 0x0}
Unfortunately I do not understand gdb's internal enough to fix it.
Any advices?
^ permalink raw reply [flat|nested] 6+ messages in thread
* threads/2383: internal-error: linux_nat_wait: Assertion `iterate_over_lwps (running_callback, NULL)' failed.
@ 2007-12-13 16:58 anemo
0 siblings, 0 replies; 6+ messages in thread
From: anemo @ 2007-12-13 16:58 UTC (permalink / raw)
To: gdb-gnats
>Number: 2383
>Category: threads
>Synopsis: internal-error: linux_nat_wait: Assertion `iterate_over_lwps (running_callback, NULL)' failed.
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Dec 13 16:58:01 UTC 2007
>Closed-Date:
>Last-Modified:
>Originator: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
>Release: 6.7.1, 6.7.50-20071213
>Organization:
>Environment:
Linux debian 2.6.18-5-686
>Description:
With 'step' scheduler-locking, stepping attached program causes assertion failure.
session log:
(gdb) break func
Breakpoint 1 at 0x8048417: file /home/anemo/tmp/foo.c, line 5.
(gdb) run
Starting program: /home/anemo/tmp/foo
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 0xb7e196c0 (LWP 14988)]
[New Thread 0xb7e18bb0 (LWP 14991)]
[Switching to Thread 0xb7e18bb0 (LWP 14991)]
Breakpoint 1, func (arg=0x0) at /home/anemo/tmp/foo.c:5
5 return NULL;
(gdb) set scheduler-locking step
(gdb) s
6 }
(gdb) s
0xb7f51240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
(gdb) s
Single stepping until exit from function start_thread,
which has no line number information.
[Thread 0xb7e18bb0 (LWP 14991) exited]
../../gdb-6.7.50.20071213/gdb/linux-nat.c:2146: internal-error: linux_nat_wait: Assertion `iterate_over_lwps (running_callback, NULL)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
stack trace:
#9 0x0809d36c in linux_nat_wait (ptid={pid = -1, lwp = 0, tid = 0},
ourstatus=0xbff62244) at ../../gdb-6.7.50.20071213/gdb/linux-nat.c:2146
#10 0x08097869 in thread_db_wait (ptid={pid = -1, lwp = 0, tid = 0},
ourstatus=0xbff62244)
at ../../gdb-6.7.50.20071213/gdb/linux-thread-db.c:874
#11 0x08111277 in wait_for_inferior ()
at ../../gdb-6.7.50.20071213/gdb/infrun.c:1035
#12 0x081113dc in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT,
step=1) at ../../gdb-6.7.50.20071213/gdb/infrun.c:855
#13 0x0810ace1 in step_1 (skip_subroutines=0,
single_inst=<value optimized out>, count_string=0x0)
at ../../gdb-6.7.50.20071213/gdb/infcmd.c:774
#14 0x08084cd3 in execute_command (p=0x83190e1 "", from_tty=1)
at ../../gdb-6.7.50.20071213/gdb/top.c:449
#15 0x0811c43c in command_handler (command=0x83190e0 "s")
at ../../gdb-6.7.50.20071213/gdb/event-top.c:518
#16 0x0811d0df in command_line_handler (rl=0x83c9ce8 "0B9\b\200�4\b")
at ../../gdb-6.7.50.20071213/gdb/event-top.c:804
#17 0x081c1c2b in rl_callback_read_char ()
at ../../gdb-6.7.50.20071213/readline/callback.c:205
#18 0x0811c5db in rl_callback_read_char_wrapper (client_data=0x0)
at ../../gdb-6.7.50.20071213/gdb/event-top.c:177
#19 0x0811c023 in handle_file_event (event_file_desc=0)
at ../../gdb-6.7.50.20071213/gdb/event-loop.c:728
#20 0x0811b4cd in process_event ()
at ../../gdb-6.7.50.20071213/gdb/event-loop.c:341
#21 0x0811bc85 in gdb_do_one_event (data=0x0)
at ../../gdb-6.7.50.20071213/gdb/event-loop.c:378
#22 0x08118f2b in catch_errors (func=0x811bb80 <gdb_do_one_event>,
func_args=0x0, errstring=0x824e045 "", mask=6)
at ../../gdb-6.7.50.20071213/gdb/exceptions.c:513
#23 0x080c53f4 in tui_command_loop (data=0x0)
at ../../gdb-6.7.50.20071213/gdb/tui/tui-interp.c:153
#24 0x081194cf in current_interp_command_loop ()
at ../../gdb-6.7.50.20071213/gdb/interps.c:276
#25 0x0807e75b in captured_command_loop (data=0x0)
at ../../gdb-6.7.50.20071213/gdb/main.c:99
#26 0x08118f2b in catch_errors (func=0x807e750 <captured_command_loop>,
func_args=0x0, errstring=0x824e045 "", mask=6)
at ../../gdb-6.7.50.20071213/gdb/exceptions.c:513
#27 0x0807ef34 in captured_main (data=0xbff627c4)
at ../../gdb-6.7.50.20071213/gdb/main.c:870
#28 0x08118f2b in catch_errors (func=0x807e790 <captured_main>,
func_args=0xbff627c4, errstring=0x824e045 "", mask=6)
at ../../gdb-6.7.50.20071213/gdb/exceptions.c:513
#29 0x0807e743 in gdb_main (args=0xbff627c4)
at ../../gdb-6.7.50.20071213/gdb/main.c:879
#30 0x0807e705 in main (argc=Cannot access memory at address 0x3a87
) at ../../gdb-6.7.50.20071213/gdb/gdb.c:33
This might be duplication of PR1988 or PR2260, but not sure.
If I did not set scheduler-locking to 'step', this problem does not happen.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/x-csrc; name="foo.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="foo.c"
I2luY2x1ZGUgPHB0aHJlYWQuaD4KCnZvaWQgKmZ1bmModm9pZCAqYXJnKQp7CglyZXR1cm4gTlVM
TDsKfQoKaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KSAKewogICAgICAgIHB0aHJlYWRf
dCBpZDsKCXB0aHJlYWRfY3JlYXRlKCZpZCwgTlVMTCwgZnVuYywgTlVMTCk7CglwdGhyZWFkX2pv
aW4oaWQsIE5VTEwpOwoJcmV0dXJuIDA7Cn0K
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-03-01 14:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-01 13:48 threads/2383: internal-error: linux_nat_wait: Assertion `iterate_over_lwps (running_callback, NULL)' failed Atsushi Nemoto
-- strict thread matches above, loose matches on Subject: below --
2008-03-01 14:58 Daniel Jacobowitz
2008-02-29 16:58 Daniel Jacobowitz
2008-02-29 16:28 Atsushi Nemoto
2008-01-26 15:48 Atsushi Nemoto
2007-12-13 16:58 anemo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).