public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Srikrishnan Sundararajan <srikrish@in.ibm.com>
To: "J. Johnston" <jjohnstn@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: lin-lwp.c:1317: internal-error: lin_lwp_wait: Assertion  `iterate_over_lwps(runing_callback, NULL)' failed.
Date: Tue, 14 Oct 2003 07:15:00 -0000	[thread overview]
Message-ID: <3F8BEA29.61F49987@in.ibm.com> (raw)
In-Reply-To: <3F2FF49E.5050707@redhat.com>

Jeff, Were you able to create a patch for this?
Srikrishnan

J. Johnston" wrote:
> 
> srikrish wrote:
> > In yesterday's post, I forgot to add that the program runs fine outside gdb.
> > Here's the output:
> > mymachine: /home/srik>./myprog somearg
> > entering main program. pid: 10861
> > In threadproc pid:10863
> >
> >  getting up from sleep
> > entering main program. pid: 10863
> > end of main: 10863
> >
> > mymachine: /home/srik>
> >
> > Is this a limitation of GDB?
> >
> 
> No, it is a bug.  The assert is historical and was left in after the nptl
> modifications.  It is meant to prevent gdb from being left hanging because there
> are no running threads to get events from.
> 
> With the advent of the new nptl model, gdb has to look for the case
> of exiting the main thread.  In nptl, when you exit the main thread, it
> means all other threads should have exited.  This is not the case for
> linuxthreads.  Since gdb is not notified when nptl lwps exit,
> it tries stopping the other lwps to see if they have exited, then
> resumes them if they are still around.
> 
> In your case, the last non-main thread remaining got to a breakpoint so it
> was stopped with pending status and the resume did not mark the thread as running.
> After gdb got rid of the main thread, it looked to see if any threads existed and if
> so, were they still running. The non-main thread was found but wasn't marked as running
> so the assert tripped.
> 
> I believe the answer is to adjust the assert to also look for pending events on
> the existing threads.
> 
> I can shortly submit a patch for consideration which you can try out.
> 
> -- Jeff J.
> 
> >
> > Subject: lin-lwp.c:1317: internal-error: lin_lwp_wait: Assertion
> > `iterate_over_lwps (runing_callback, NULL)' failed.
> >
> >
> >
> >>Hi,
> >>I am getting an assertion failure/gdb-internal-error while running a
> >>multi-threaded program using the GDB20030731. Can some one point out if
> >
> > this
> >
> >>is a known bug or is there a workaround?
> >>
> >>Error Message: lin-lwp.c:1317: internal-error: lin_lwp_wait: Assertion
> >>`iterate_over_lwps (runing_callback, NULL)' failed.
> >>
> >>The test program and output follows. I am using 2.4.19-3Suse-SMP kernel.
> >>(linuxthreads)
> >>Thanks,
> >>Srikrishnan
> >>
> >>Test Program: Please note that I am calling exec of the same program
> >
> > without
> >
> >>arguments.
> >>#include <stdio.h>
> >>#include <pthread.h>
> >>void * threadproc(void * junk)
> >>{
> >> int i;
> >> printf("In threadproc pid:%d \n", getpid());
> >>    printf("\n getting up from sleep \n");
> >>  execv("myprog",0);=20
> >>    printf("exec failed \n");
> >>}
> >>
> >>int main(int argc, char * argv)
> >>{
> >> int i;
> >>    void * ret;
> >> pthread_t newthread;
> >>    printf("entering main program. pid: %d \n", getpid());
> >> if(argc >1)
> >> {
> >>  pthread_create(&newthread, NULL, threadproc, NULL);
> >>  printf("back to main. pid:%d \n",getpid());
> >>  }
> >>    printf("end of main: %d \n", getpid());
> >>}
> >>
> >>
> >>OUTOUT WHILE USING GDB after enabling printing of verbose/debug statements
> >>in gdb/lin-lwp.c
> >>
> >>
> >>>gdbdir/gdb myprog
> >>
> >>GNU gdb 20030731
> >>Copyright 2003 Free Software Foundation, Inc.
> >>GDB is free software, covered by the GNU General Public License, and you
> >
> > are
> >
> >>welcome to change it and/or distribute copies of it under certain
> >>conditions.
> >>Type "show copying" to see the conditions.
> >>There is absolutely no warranty for GDB.  Type "show warranty" for
> >
> > details.
> >
> >>This GDB was configured as "s390-ibm-linux"...
> >>(gdb) run somearg
> >>Starting program: /home/fultonm/bug3380/test3380nosleep somearg
> >>CW:  waitpid 2122 received Trace/breakpoint trap (stopped)
> >>CW:  waitpid 2122 received Trace/breakpoint trap (stopped)
> >>CW:  waitpid 2122 received Trace/breakpoint trap (stopped)
> >>[New Thread 1024 (LWP 2122)]
> >>LLR: PTRACE_SINGLESTEP process 2122, 0 (resume event thread)
> >>LLW: waitpid 2122 received Trace/breakpoint trap (stopped)
> >>LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 2122.
> >>SEL: Select single-step LWP 2122
> >>LLW: trap_ptid is process 2122.
> >>LLR: PTRACE_CONT process 2122, 0 (resume event thread)
> >>LLW: waitpid 2122 received Trace/breakpoint trap (stopped)
> >>LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 2122.
> >>LLW: trap_ptid is process 2122.
> >>LLR: PTRACE_SINGLESTEP process 2122, 0 (resume event thread)
> >>LLW: waitpid 2122 received Trace/breakpoint trap (stopped)
> >>LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 2122.
> >>SEL: Select single-step LWP 2122
> >>LLW: trap_ptid is process 2122.
> >>LLR: PTRACE_CONT process 2122, 0 (resume event thread)
> >>LLW: waitpid 2122 received Trace/breakpoint trap (stopped)
> >>LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 2122.
> >>LLW: trap_ptid is process 2122.
> >>LLR: PTRACE_SINGLESTEP process 2122, 0 (resume event thread)
> >>LLW: waitpid 2122 received Trace/breakpoint trap (stopped)
> >>LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 2122.
> >>SEL: Select single-step LWP 2122
> >>LLW: trap_ptid is process 2122.
> >>LLR: PTRACE_CONT process 2122, 0 (resume event thread)
> >>LLW: waitpid 2122 received Trace/breakpoint trap (stopped)
> >>LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 2122.
> >>LLW: trap_ptid is process 2122.
> >>[New Thread 2049 (LWP 2123)]
> >>LLAL: PTRACE_ATTACH LWP 2123, 0, 0 (OK)
> >>LLAL: waitpid LWP 2123 received Stopped (signal) (stopped)
> >>LLR: PTRACE_SINGLESTEP process 2122, 0 (resume event thread)
> >>LLW: waitpid 2122 received Trace/breakpoint trap (stopped)
> >>LLTA: PTRACE_PEEKUSER LWP 2122, 0, 0 (OK)
> >>LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 2122.
> >>SEL: Select single-step LWP 2122
> >>LLW: trap_ptid is LWP 2122.
> >>RC:  PTRACE_CONT LWP 2123, 0, 0 (resume sibling)
> >>LLR: PTRACE_CONT process 2122, 0 (resume event thread)
> >>LLW: waitpid 2123 received Real-time signal 0 (stopped)
> >>LLTA: PTRACE_PEEKUSER LWP 2123, 0, 0 (OK)
> >>LLW: PTRACE_CONT LWP 2123, Unknown signal 77 (preempt 'handle')
> >>LLW: waitpid 2123 received Trace/breakpoint trap (stopped)
> >>LLTA: PTRACE_PEEKUSER LWP 2123, 0, 0 (OK)
> >>LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 2123.
> >>SC:  kill LWP 2122 **<SIGSTOP>**
> >>SC:  lwp kill 0 ERRNO-OK
> >>SWC: waitpid LWP 2122 received Stopped (signal) (stopped)
> >>SWC: CALLING LLTA
> >>LLTA: PTRACE_PEEKUSER LWP 2122, 0, 0 (OK)
> >>LLW: trap_ptid is LWP 2123.
> >>[New Thread 1026 (LWP 2124)]
> >>LLAL: PTRACE_ATTACH LWP 2124, 0, 0 (OK)
> >>LLAL: waitpid LWP 2124 received Stopped (signal) (stopped)
> >>LLR: PTRACE_SINGLESTEP process 2123, 0 (resume event thread)
> >>LLW: waitpid 2123 received Trace/breakpoint trap (stopped)
> >>LLTA: PTRACE_PEEKUSER LWP 2123, 0, 0 (OK)
> >>LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 2123.
> >>SEL: Select single-step LWP 2123
> >>LLW: trap_ptid is LWP 2123.
> >>RC:  PTRACE_CONT LWP 2124, 0, 0 (resume sibling)
> >>RC:  PTRACE_CONT LWP 2122, 0, 0 (resume sibling)
> >>LLR: PTRACE_CONT process 2123, 0 (resume event thread)
> >>LLW: waitpid 2124 received Real-time signal 0 (stopped)
> >>LLTA: PTRACE_PEEKUSER LWP 2124, 0, 0 (OK)
> >>LLW: PTRACE_CONT LWP 2124, Unknown signal 77 (preempt 'handle')
> >>In threadproc pid:2124
> >>LLW: waitpid 2122 received Real-time signal 0 (stopped)
> >> getting up from sleep
> >>LLTA: PTRACE_PEEKUSER LWP 2122, 0, 0 (OK)
> >>back to main. pid:2122
> >>LLW: PTRACE_CONT LWP 2122, Unknown signal 77 (preempt 'handle')
> >>LLW: waitpid 2122 received Real-time signal 1 (stopped)
> >>LLTA: PTRACE_PEEKUSER LWP 2122, 0, 0 (OK)
> >>LLW: PTRACE_CONT LWP 2122, Real-time signal 13 (preempt 'handle')
> >>LLW: waitpid 2124 received Real-time signal 0 (stopped)
> >>LLTA: PTRACE_PEEKUSER LWP 2124, 0, 0 (OK)
> >>LLW: PTRACE_CONT LWP 2124, Unknown signal 77 (preempt 'handle')
> >>LLW: waitpid 2123 received 0 (exited)
> >>LLW: LWP 2123 exited.
> >>LLW: waitpid 2122 received 0 (exited)
> >>SC:  kill LWP 2124 **<SIGSTOP>**
> >>SC:  lwp kill 0 ERRNO-OK
> >>SWC: waitpid LWP 2124 received Trace/breakpoint trap (stopped)
> >>SWC: CALLING LLTA
> >>LLTA: PTRACE_PEEKUSER LWP 2124, 0, 0 (OK)
> >>PTRACE_CONT LWP 2124, 0, 0 (OK)
> >>SWC: Candidate SIGTRAP event in LWP 2124
> >>SWC: waitpid LWP 2124 received Stopped (signal) (stopped)
> >>SWC: CALLING LLTA
> >>LLTA: PTRACE_PEEKUSER LWP 2124, 0, 0 (OK)
> >>LLW: LWP 2122 exited.
> >>lin-lwp.c:1317: internal-error: lin_lwp_wait: Assertion `iterate_over_lwps
> >>(run
> >>ing_callback, NULL)' failed.
> >>A problem internal to GDB has been detected,
> >>further debugging may prove unreliable.
> >>Quit this debugging session? (y or n) y
> >>
> >>Create a core file of GDB? (y or n) y
> >>Abort
> >>mymachine: /home/srik>
> >>
> >>
> >>
> >
> >

  parent reply	other threads:[~2003-10-14  7:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-04 15:53 lin-lwp.c:1317: internal-error: lin_lwp_wait: Assertion `iterate_over_lwps (runing_callback, " srikrish
2003-08-05 15:49 ` srikrish
2003-08-05 18:17   ` J. Johnston
2003-08-06 10:25     ` srikrish
2003-10-14  7:15     ` Srikrishnan Sundararajan [this message]
2003-10-14 13:00       ` lin-lwp.c:1317: internal-error: lin_lwp_wait: Assertion `iterate_over_lwps(runing_callback, " Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F8BEA29.61F49987@in.ibm.com \
    --to=srikrish@in.ibm.com \
    --cc=gdb@sources.redhat.com \
    --cc=jjohnstn@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).