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): gdb-6.6-36.fc8.x86_64 How reproducible: Always 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 found.
(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.
Ah, ulimit. I knew I'd probably forgotten something obvious. The kernel is kernel-2.6.23.1-49.fc8.x86_64 and glibc is glibc-2.7-2.x86_64 The gdb core file is too large to attach, so you can find it at http://www.ioerror.us/tmp/core.23485.bz2
One 403 Forbidden there. Thanks.
> 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.
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. ;-) Thanks, Jan
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.
This issue seems to have been resolved as of Fedora 9. I can no longer reproduce the problem.