If I generate a coredump of the web process and try to load it with GDB, it makes GDB crash. GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
what's the stack trace? Here I have: #41412 0x00000000006d305c in d_print_comp () #41413 0x00000000006d13ae in d_print_comp () #41414 0x00000000006d1649 in d_print_comp () #41415 0x00000000006d10d7 in d_print_comp () #41416 0x00000000006d1649 in d_print_comp () #41417 0x00000000006d064b in d_print_comp () #41418 0x00000000006d417e in d_print_function_type.isra () #41419 0x00000000006d0bf5 in d_print_comp () #41420 0x00000000006d305c in d_print_comp () #41421 0x00000000006d13ae in d_print_comp () #41422 0x00000000006d1649 in d_print_comp () #41423 0x00000000006d10d7 in d_print_comp () #41424 0x00000000006d1649 in d_print_comp () #41425 0x00000000006d064b in d_print_comp () #41426 0x00000000006d417e in d_print_function_type.isra () #41427 0x00000000006d0bf5 in d_print_comp () #41428 0x00000000006d305c in d_print_comp () #41429 0x00000000006d13ae in d_print_comp () #41430 0x00000000006d1649 in d_print_comp () #41431 0x00000000006d10d7 in d_print_comp () #41432 0x00000000006d1649 in d_print_comp () #41433 0x00000000006d064b in d_print_comp () #41434 0x00000000006d417e in d_print_function_type.isra () #41435 0x00000000006d0bf5 in d_print_comp () #41436 0x00000000006d305c in d_print_comp () #41437 0x00000000006d13ae in d_print_comp () #41438 0x00000000006d1649 in d_print_comp () #41439 0x00000000006d10d7 in d_print_comp () #41440 0x00000000006d1649 in d_print_comp () #41441 0x00000000006d2a68 in d_print_comp () #41442 0x00000000006d305c in d_print_comp () #41443 0x00000000006d76cc in cplus_demangle_print_callback () #41444 0x00000000006d78d6 in d_demangle_callback () #41445 0x00000000006d79e7 in d_demangle () #41446 0x00000000006d7b8e in cplus_demangle_v3 () #41447 0x00000000006c9f46 in cplus_demangle () #41448 0x00000000006705ab in bfd_demangle () #41449 0x000000000052a9c9 in symbol_set_names () #41450 0x0000000000593836 in prim_record_minimal_symbol_full () #41451 0x00000000004c5c76 in elf_symtab_read () #41452 0x00000000004c631d in elf_symfile_read () #41453 0x0000000000535f49 in read_symbols () #41454 0x0000000000535ade in symbol_file_add_with_addrs () #41455 0x000000000062e409 in solib_read_symbols () #41456 0x000000000062e840 in solib_add () #41457 0x000000000046eee6 in enable_break () #41458 0x0000000000544d65 in post_create_inferior () #41459 0x0000000000550550 in start_remote () #41460 0x0000000000483c39 in remote_start_remote () #41461 0x000000000048435b in remote_open_1 () #41462 0x00000000006181ef in execute_command () #41463 0x0000000000619011 in command_loop () #41464 0x00000000006190d9 in read_command_file () #41465 0x000000000049e4e2 in script_from_file () #41466 0x00000000004a077b in source_script_with_search () #41467 0x000000000055b9fe in catch_command_errors_const () #41468 0x000000000055e42f in captured_main () #41469 0x000000000055b89a in catch_errors () #41470 0x000000000055e974 in gdb_main () #41471 0x0000000000455dfe in main ()
That's a bt -60 of gdb running in gdb.
This issue doesn't happen with gdb 7.9.1... Maybe some older version between 7.7 and 7.9 also works.
Shouldn't this be reported on gdb Bugzilla, rather than here? :)
(In reply to comment #4) > Shouldn't this be reported on gdb Bugzilla, rather than here? :) Not even worth it if it's already fixed.
(In reply to comment #5) > (In reply to comment #4) > > Shouldn't this be reported on gdb Bugzilla, rather than here? :) > > Not even worth it if it's already fixed. I reported it here because I thought it had been a consequence of all building issues that were hitting trunk last week. Anyway, even if this was true, gdb shouldn't be crashing, but as Phil says, bug seems to be fixed now. I will just have to suffer the pain until the new working version hits Debian testing :)