This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/12905] New: gdb 7.2 asserts "thread.c:598: internal-error:Assertion `tp' failed." on x86_64-sun-solaris2.10
- From: "tim.mooney at ndsu dot edu" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 16 Jun 2011 21:17:59 +0000
- Subject: [Bug gdb/12905] New: gdb 7.2 asserts "thread.c:598: internal-error:Assertion `tp' failed." on x86_64-sun-solaris2.10
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=12905
Summary: gdb 7.2 asserts "thread.c:598: internal-error:
Assertion `tp' failed." on x86_64-sun-solaris2.10
Product: gdb
Version: 7.2
Status: NEW
Severity: normal
Priority: P2
Component: gdb
AssignedTo: unassigned@sourceware.org
ReportedBy: tim.mooney@ndsu.edu
I built gdb-7.2 on x86_64-sun-solaris2.10 with the Sun Workshop 12u1 toolchain.
gdb was built as an ELF64 executable.
I've tried debugging several different programs now using gdb, and in each case
it immediately asserts in thread.c line 598:
$cd GConf-2.32.1/
$gdb /local/gnu/bin/gnome-terminal
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /local/gnu/bin/gnome-terminal...done.
(gdb) dir .:backends:gconf:gsettings
Source directories searched:
/local/src/RPM/BUILD/GConf-2.32.1:/local/src/RPM/BUILD/GConf-2.32.1/backends:/local/src/RPM/BUILD/GConf-2.32.1/gconf:/local/src/RPM/BUILD/GConf-2.32.1/gsettings:$cdir:$cwd
(gdb) run
Starting program: /local/gnu/bin/gnome-terminal
[New LWP 2]
[LWP 2 exited]
thread.c:598: internal-error: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
thread.c:598: internal-error: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
Abort (core dumped)
If I try debug gdb + the core with itself, I get the same error.
dbx has this to say:
$dbx /local/gnu/bin/gdb core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.7' in your
.dbxrc
Reading gdb
core file header read successfully
Reading ld.so.1
Reading libintl.so.8.0.2
Reading libc.so.1
Reading libdl.so.1
Reading libcurses.so.1
Reading libz.so.1.2.3
Reading libsocket.so.1
Reading libnsl.so.1
Reading libm.so.2
Reading librt.so.1
Reading libpython2.6.so.1.0
Reading libexpat.so.1.5.2
Reading libaio.so.1
Reading libmd.so.1
Reading libc_db.so.1
program terminated by signal ABRT (Abort)
0xfffffd7fff2fcdba: __lwp_kill+0x000a: jae __lwp_kill+0x18 [
0xfffffd7fff2fcdc8, .+0xe ]
Current function is dump_core
1010 abort (); /* NOTE: GDB has only three calls to abort().
*/
(dbx) where
[1] __lwp_kill(0x1, 0x6, 0xffffffffb6a368e0, 0xfffffd7fff2fd6ee,
0xfffffd7fffdfe0d0, 0x6), at 0xfffffd7fff2fcdba
[2] _thr_kill(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff2f56b3
[3] raise(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff2a1fe9
[4] abort(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff2813b0
=>[5] dump_core(), line 1010 in "utils.c"
[6] internal_vproblem(problem = 0xe2c520, file = 0xdd3d30 "thread.c", line =
598, fmt = 0xdd3c78 "Assertion `%s' failed.", ap = 0xfffffd7fffdfe338), line
1166 in "utils.c"
[7] internal_verror(file = 0xdd3d30 "thread.c", line = 598, fmt = 0xdd3c78
"Assertion `%s' failed.", ap = 0xfffffd7fffdfe338), line 1191 in "utils.c"
[8] internal_error(file = 0xdd3d30 "thread.c", line = 598, string = 0xdd3c78
"Assertion `%s' failed.", ... = 0x2, ...), line 1201 in "utils.c"
[9] is_thread_state(ptid = RECORD, state = THREAD_EXITED), line 598 in
"thread.c"
[10] is_exited(ptid = RECORD), line 611 in "thread.c"
[11] switch_to_thread(ptid = RECORD), line 901 in "thread.c"
[12] startup_inferior(ntraps = 2), line 471 in "fork-child.c"
[13] procfs_init_inferior(ops = 0xe8d440, pid = 17285), line 4714 in
"procfs.c"
[14] procfs_create_inferior(ops = 0xe8d440, exec_file = 0x1063260
"/local/gnu/bin/gnome-terminal", allargs = 0x10812e0 "", env = 0x1066b70,
from_tty = 1), line 4941 in "procfs.c"
[15] find_default_create_inferior(ops = 0xe6aea8, exec_file = 0x1063260
"/local/gnu/bin/gnome-terminal", allargs = 0x10812e0 "", env = 0x1066b70,
from_tty = 1), line 2598 in "target.c"
[16] target_create_inferior(exec_file = 0x1063260
"/local/gnu/bin/gnome-terminal", args = 0x10812e0 "", env = 0x1066b70, from_tty
= 1), line 486 in "target.c"
[17] run_command_1(args = (nil), from_tty = 1, tbreak_at_main = 0), line 566
in "infcmd.c"
[18] run_command(args = (nil), from_tty = 1), line 596 in "infcmd.c"
[19] do_cfunc(c = 0xeb8df0, args = (nil), from_tty = 1), line 67 in
"cli-decode.c"
[20] cmd_func(cmd = 0xeb8df0, args = (nil), from_tty = 1), line 1771 in
"cli-decode.c"
[21] execute_command(p = 0xe6df63 "", from_tty = 1), line 422 in "top.c"
[22] command_handler(command = 0xe6df60 ""), line 498 in "event-top.c"
[23] command_line_handler(rl = 0xe8b8a0 "run"), line 702 in "event-top.c"
[24] rl_callback_read_char(), line 205 in "callback.c"
[25] rl_callback_read_char_wrapper(client_data = (nil)), line 178 in
"event-top.c"
[26] stdin_event_handler(error = 0, client_data = (nil)), line 433 in
"event-top.c"
[27] handle_file_event(data = UNION), line 817 in "event-loop.c"
[28] process_event(), line 399 in "event-loop.c"
[29] gdb_do_one_event(data = (nil)), line 464 in "event-loop.c"
[30] catch_errors(func = 0x9334f0 = &gdb_do_one_event(void *data), func_args
= (nil), errstring = 0xdaa1b8 "", mask = 6), line 518 in "exceptions.c"
[31] tui_command_loop(data = (nil)), line 171 in "tui-interp.c"
[32] current_interp_command_loop(), line 291 in "interps.c"
[33] captured_command_loop(data = (nil)), line 227 in "main.c"
[34] catch_errors(func = 0x5a78d0 = &`gdb`main.c`captured_command_loop(void
*data), func_args = (nil), errstring = 0xd8aa10 "", mask = 6), line 518 in
"exceptions.c"
[35] captured_main(data = 0xfffffd7fffdfed98), line 910 in "main.c"
[36] catch_errors(func = 0x5a7950 = &`gdb`main.c`captured_main(void *data),
func_args = 0xfffffd7fffdfed98, errstring = 0xd8aa18 "", mask = 6), line 518 in
"exceptions.c"
[37] gdb_main(args = 0xfffffd7fffdfed98), line 919 in "main.c"
[38] main(argc = 2, argv = 0xfffffd7fffdfedf8), line 34 in "gdb.c"
(dbx) up
Current function is internal_verror
1191 internal_vproblem (&internal_error_problem, file, line, fmt, ap);
(dbx) up
Current function is internal_error
1201 internal_verror (file, line, string, ap);
(dbx) up
Current function is is_thread_state
598 gdb_assert (tp);
(dbx) list
598 gdb_assert (tp);
599 return tp->state_ == state;
600 }
601
602 int
603 is_stopped (ptid_t ptid)
604 {
605 return is_thread_state (ptid, THREAD_STOPPED);
606 }
(dbx) print tp
tp = (nil)
(dbx) print ptid
ptid = {
pid = 17285
lwp = 2
tid = 0
}
As the output before the assert shows, LWP 2 exited before the assert, which
I'm going to guess is what caused the assertion.
I don't see any options to configure to choose which thread model to use (some
packages on Solaris allow you to choose between the Solaris lwp model and more
traditional pthreads), so the threading would be the configure defaults.
In particular, I see:
$ grep -i '^checking.*thread' ~/x86_64-solaris2.10/gdb-7.2.out
checking for a thread-safe mkdir -p... checking for a thread-safe mkdir -p...
cc -c -DHAVE_CONFIG_H -Xa -xs -g -xtarget=native -m64 -xarch=native
-I/local/gnu/include -I/local/gnu/include -I/local/include -I/local/gnu/include
-I/local/gnu/include -I/local/include -I. -I./../include ./hex.c -o hex.o
checking for a thread-safe mkdir -p... ../install-sh -c -d
checking thread_db.h usability... yes
checking thread_db.h presence... yes
checking for thread_db.h... yes
checking for struct thread.td_pcb... no
checking for Solaris thread debugging library... yes
checking whether <thread_db.h> has TD_NOTALLOC... no
checking whether <thread_db.h> has TD_VERSION... no
checking whether <thread_db.h> has TD_NOTLS... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.