This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
threads/1518: Application terminates when running under gdb
- From: bryner at brianryner dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 18 Jan 2004 08:13:11 -0000
- Subject: threads/1518: Application terminates when running under gdb
- Reply-to: bryner at brianryner dot com
>Number: 1518
>Category: threads
>Synopsis: Application terminates when running under gdb
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Jan 18 08:18:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: bryner@brianryner.com
>Release: 2004-01-18-cvs
>Organization:
>Environment:
Fedora Core 1 (kernel 2.4.22-1.2149.nptl, glibc 2.3.2-101.4)
>Description:
When running Mozilla under gdb, it often terminates during startup, with the message:
Couldn't get registers: No such process.
Here's the output of 'set debug lin-lwp 1' leading up to the abnormal exit:
RC: PTRACE_CONT LWP 6051, 0, 0 (resume sibling)
RC: PTRACE_CONT LWP 6050, 0, 0 (resume sibling)
RC: PTRACE_CONT LWP 6049, 0, 0 (resume sibling)
RC: PTRACE_CONT LWP 6045, 0, 0 (resume sibling)
LLR: PTRACE_CONT process 6048, 0 (resume event thread)
LLW: waitpid 6045 received Unknown signal 0 (terminated)
SC: kill LWP 6051 **<SIGSTOP>**
SC: lwp kill -1 No such process
WL: LWP 6051 vanished.
WL: LWP 6051 exited.
SC: kill LWP 6050 **<SIGSTOP>**
SC: lwp kill -1 No such process
WL: LWP 6050 vanished.
WL: LWP 6050 exited.
SC: kill LWP 6049 **<SIGSTOP>**
SC: lwp kill -1 No such process
WL: LWP 6049 vanished.
WL: LWP 6049 exited.
SC: kill LWP 6048 **<SIGSTOP>**
SC: lwp kill -1 No such process
WL: LWP 6048 vanished.
WL: LWP 6048 exited.
LLW: LWP 6045 exited.
LLW: Candidate event Unknown signal 0 (terminated) in LWP 6045.
I can provide other debug output if it would be helpful. Also, I believe this problem has been around for awhile... I'm not sure it has ever worked correctly with NPTL.
>How-To-Repeat:
- Do a stock debug build of Mozilla
- Start gdb via the included shell script:
./mozilla -d gdb -g
(this sets up LD_LIBRARY_PATH and then starts gdb on the binary)
The problem happens much less often on optimized builds of Mozilla.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: