Summary: | Crash when running binary a second time in the same session | ||
---|---|---|---|
Product: | gdb | Reporter: | Hyrum Wright <hyrum> |
Component: | gdb | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | tromey |
Priority: | P2 | ||
Version: | 7.4 | ||
Target Milestone: | 7.5 | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Hyrum Wright
2012-01-24 17:53:12 UTC
For what it's worth, I tried reproducing this on my Unbuntu Oneric box, but it doesn't seem to be a problem there. You may need to rebuild gdb without optimization to see which free is really failing. In 7.4, line 597 of objfiles.c isn't a direct call to free: gdb_bfd_unref (objfile->obfd); Rebuilt without optimization (which, incidentally is itself non-trivial), and I now get the following stack trace: [[[ (gdb) bt #0 0x00007fff94e0e6c0 in malloc_error_break () #1 0x00007fff94e0e805 in free () #2 0x0000000100333dc2 in xfree (ptr=0x10046e998) at common-utils.c:107 #3 0x000000010020271a in gdb_bfd_unref (abfd=0x100be5e50) at objfiles.c:1557 #4 0x00000001001ff67b in free_objfile (objfile=0x10124e800) at objfiles.c:597 #5 0x0000000100200c0e in objfile_purge_solibs () at objfiles.c:986 #6 0x00000001000267b9 in no_shared_libraries (ignored=0x0, from_tty=1) at solib.c:1205 #7 0x00000001001e9fbd in target_pre_inferior (from_tty=1) at target.c:2479 #8 0x0000000100186a56 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0) at infcmd.c:516 #9 0x0000000100186d87 in run_command (args=0x0, from_tty=1) at infcmd.c:620 #10 0x000000010007487c in do_cfunc (c=0x100b40300, args=0x0, from_tty=1) at cli-decode.c:67 #11 0x0000000100079117 in cmd_func (cmd=0x100b40300, args=0x0, from_tty=1) at cli-decode.c:1810 #12 0x00000001002eef5c in execute_command (p=0x100b0a221 "", from_tty=1) at top.c:441 #13 0x00000001001ba2ca in command_handler (command=0x100b0a220 "") at event-top.c:435 #14 0x00000001001baad3 in command_line_handler (rl=0x100becf80 "??\v\020") at event-top.c:636 #15 0x0000000100359359 in rl_callback_read_char () at callback.c:220 #16 0x00000001001b9a11 in rl_callback_read_char_wrapper (client_data=0x0) at event-top.c:169 #17 0x00000001001ba177 in stdin_event_handler (error=0, client_data=0x0) at event-top.c:375 #18 0x00000001001b883a in handle_file_event (data={ptr = 0x7fff00000000, integer = 0}) at event-loop.c:827 #19 0x00000001001b7c1e in process_event () at event-loop.c:401 #20 0x00000001001b7d1d in gdb_do_one_event () at event-loop.c:465 #21 0x00000001001b7d92 in start_event_loop () at event-loop.c:490 #22 0x00000001001b9a5b in cli_command_loop () at event-top.c:182 #23 0x00000001001ae49a in current_interp_command_loop () at interps.c:309 #24 0x00000001001af2de in captured_command_loop (data=0x0) at main.c:232 #25 0x00000001001ad51a in catch_errors (func=0x1001af2c0 <captured_command_loop>, func_args=0x0, errstring=0x100486080 "", mask=6) at exceptions.c:502 #26 0x00000001001b0a25 in captured_main (data=0x7fff5fbffa20) at main.c:942 #27 0x00000001001ad51a in catch_errors (func=0x1001af340 <captured_main>, func_args=0x7fff5fbffa20, errstring=0x100486080 "", mask=6) at exceptions.c:502 #28 0x00000001001b0bc4 in gdb_main (args=0x7fff5fbffa20) at main.c:951 #29 0x0000000100001423 in main (argc=2, argv=0x7fff5fbffa80) at gdb.c:34 ]]] It looks like the calls to gdb_bfd_unref() and xfree() were optimized out in the first version, but things are otherwise the same. Thanks. It is crashing when freeing the BFD's filename. I think this patch would probably help: http://sourceware.org/ml/gdb-patches/2011-12/msg00473.html I'll look into pushing in the parts of that series that make sense in isolation. Thanks for taking a look. Unfortunately, the referenced patch doesn't apply cleanly to a 7.4 tree. Should I attempt to apply it elsewhere? (In reply to comment #5) > Thanks for taking a look. > > Unfortunately, the referenced patch doesn't apply cleanly to a 7.4 tree. > Should I attempt to apply it elsewhere? I haven't rebased the patch in a while, so I'm afraid it will only apply to whatever version I was using back then. According to git this was 9c737a359a2c2730e685ef363173e7a6921974a7 I'll try to rebase soon. Tristan just committed a patch which should fix this problem: http://sourceware.org/ml/gdb-patches/2012-02/msg00098.html Could you try cvs head and say whether it works for you? Rather than checkout a completely new tree from CVS, I manually applied the patch to my copy of the 7.4 source code. It appears to fix the problem: [[[ $ /usr/local/bin/gdb ./a.out GNU gdb (GDB) 7.4 Copyright (C) 2012 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 "x86_64-apple-darwin11.3.0". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /Users/Hyrum/dev/test/a.out...Reading symbols from /Users/Hyrum/dev/test/a.out.dSYM/Contents/Resources/DWARF/a.out...done. done. (gdb) r Starting program: /Users/Hyrum/dev/test/a.out Hello, World! [Inferior 1 (process 54972) exited normally] (gdb) r Starting program: /Users/Hyrum/dev/test/a.out Hello, World! [Inferior 1 (process 54974) exited normally] (gdb) r Starting program: /Users/Hyrum/dev/test/a.out Hello, World! [Inferior 1 (process 54976) exited normally] (gdb) r Starting program: /Users/Hyrum/dev/test/a.out Hello, World! [Inferior 1 (process 54978) exited normally] (gdb) ]]] Thanks! Thanks for checking. I'm closing this. |