Bug 406961 - gdb assertion failure debugging threaded application
gdb assertion failure debugging threaded application
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jan Kratochvil
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-11-30 16:28 EST by Michael Hampton
Modified: 2008-05-17 14:06 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-17 14:06:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
gzipped simple threading testcase. (3.13 KB, application/octet-stream)
2007-12-02 07:58 EST, Jan Kratochvil
no flags Details

  None (edit)
Description Michael Hampton 2007-11-30 16:28:20 EST
Description of problem:

While debugging an intermittent crash in Firefox (bug to be filed elsewhere)
with gdb, gdb gives an assertion failure as follows:

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaaab03afd in MarkSharpObjects (cx=0x1604d80, obj=0xd52560, idap=0x0)
    at jsobj.c:474
474                 ok = OBJ_LOOKUP_PROPERTY(cx, obj, id, &obj2, &prop);
Current language:  auto; currently c
(gdb) thread apply all backtrace full
../../gdb/linux-nat.c:2701: internal-error: linux_nat_thread_alive: Assertion
`is_lwp (ptid)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

../../gdb/linux-nat.c:2701: internal-error: linux_nat_thread_alive: Assertion
`is_lwp (ptid)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start threaded application e.g. Firefox, in gdb. Wait for app to seg fault.
2. Enter "thread apply all backtrace full".
3. Further debugging is impossible.
Actual results:
gdb refuses to print a backtrace and gives the assertion failure listed above.

Expected results:
a backtrace of the program being debugged

Additional info:
gdb said it was generating a core file of itself, but the core file could not be
Comment 1 Jan Kratochvil 2007-11-30 17:00:45 EST
(In reply to comment #0)
> How reproducible:
> Always

Unfortunately it works for me, could you best post the core file from GDB as
indicated below?  Please provide at least the kernel version running, this
threading stuff there is a bit fragile.

> Additional info:
> gdb said it was generating a core file of itself, but the core file could not
> be found.

Please check `ulimit -c', it is usually 0 (/etc/profile), type `ulimit -c
unlimited'.  Well GDB could raise it itself when it interactively asks, thanks.
Comment 2 Michael Hampton 2007-12-01 18:01:18 EST
Ah, ulimit. I knew I'd probably forgotten something obvious. 

The kernel is kernel- and glibc is glibc-2.7-2.x86_64

The gdb core file is too large to attach, so you can find it at
Comment 3 Jan Kratochvil 2007-12-01 21:59:10 EST
One 403 Forbidden there.
Comment 4 Michael Hampton 2007-12-01 22:15:07 EST
> One 403 Forbidden there.
> Thanks.

First I forget ulimit, then I forget chmod. It's just not my week. This should
be fixed. Sorry for the trouble.
Comment 5 Jan Kratochvil 2007-12-02 07:58:44 EST
Created attachment 275071 [details]
gzipped simple threading testcase.

Attached testcase just does pthread_create() and pthread_join().
You should get messages like these:
$ gdb
GNU gdb Red Hat Linux (6.6-36.fc8rh)
Copyright (C) 2006 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 "x86_64-redhat-linux-gnu".
(gdb) file /tmp/simplethread
Reading symbols from /tmp/simplethread...done.
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) r
Starting program: /tmp/simplethread 
[Thread debugging using libthread_db enabled]
[New process 4248]
[New Thread 1084229968 (LWP 4251)]
[New Thread 46912496216832 (LWP 4248)]
[Thread 1084229968 (LWP 4251) exited]

Program exited normally.
(gdb) q

In your GDB core file while debugging Firefox you have `lwp_list' OK:
$18 = {pid = 23039, lwp = 23480, tid = 0}
$19 = {pid = 23039, lwp = 23062, tid = 0}
$20 = {pid = 23039, lwp = 23057, tid = 0}
$21 = {pid = 23039, lwp = 23056, tid = 0}
$22 = {pid = 23039, lwp = 23055, tid = 0}
$23 = {pid = 23039, lwp = 23054, tid = 0}
$24 = {pid = 23039, lwp = 23053, tid = 0}
$25 = {pid = 23039, lwp = 23052, tid = 0}
$26 = {pid = 23039, lwp = 23051, tid = 0}
$27 = {pid = 23039, lwp = 23050, tid = 0}
$28 = {pid = 23039, lwp = 23049, tid = 0}
$29 = {pid = 23039, lwp = 23039, tid = 0}

but `thread_list' is obsolete there:
$15 = {pid = 23039, lwp = 0, tid = 0}
$16 = {pid = 23039, lwp = 23039, tid = 46912496378960}
$17 = {pid = 23039, lwp = 23039, tid = 0}

because GDB was NOT using threads support that time:
(gdb) p using_thread_db
$34 = 0
(gdb) p current_target.to_find_new_threads
$35 = (void (*)(void)) 0x4eca10 <target_ignore>

I expect your system does not print the message
  [Thread debugging using libthread_db enabled]
but I have no clue why.  If the attached simple testcase works a remote login
would be the best choice.  Please do not forget `chmod +x' after ungzipping it.

Comment 6 Michael Hampton 2007-12-03 20:48:15 EST
Yep, the simple testcase works, and it does print the message:
[Thread debugging using libthread_db enabled]

Why this is not so when debugging Firefox, I don't know. I would appreciate any
hints :)

I don't think I can arrange a remote login, since this is my laptop and incoming
ssh gets routed to another system in the house. And it's my laptop and not very
often here anyway.
Comment 7 Michael Hampton 2008-05-17 14:06:53 EDT
This issue seems to have been resolved as of Fedora 9. I can no longer reproduce
the problem.

Note You need to log in before you can comment on or make changes to this bug.