public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "tim.mooney at ndsu dot edu" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug gdb/12905] New: gdb 7.2 asserts "thread.c:598: internal-error: Assertion `tp' failed." on x86_64-sun-solaris2.10 Date: Thu, 16 Jun 2011 21:18:00 -0000 [thread overview] Message-ID: <bug-12905-4717@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2011-06-16 21:18 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-06-16 21:18 tim.mooney at ndsu dot edu [this message] 2011-06-17 9:21 ` [Bug gdb/12905] " pedro at codesourcery dot com 2012-04-20 17:17 ` tim.mooney at ndsu dot edu
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=bug-12905-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /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: linkBe 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).