[Bug gdb/14290] New: gdb_bfd_unref frees an already freed memory block

[Bug gdb/14290] New: gdb_bfd_unref frees an already freed memory block

[johnw at boostpro dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

             Bug #: 14290
           Summary: gdb_bfd_unref frees an already freed memory block
           Product: gdb
           Version: 7.4
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
        AssignedTo: unassigned@sourceware.org
        ReportedBy: johnw@boostpro.com
    Classification: Unclassified


In gdb_bfd_unref, objfiles.c, the last lines in that function are:

    name = bfd_get_filename (abfd);
    gdb_bfd_close_or_warn (abfd);
    xfree (name);

The memory checker on OS X aborts gdb because xfree here is freeing a memory
block that was already freed elsewhere.

Reproducing this on OS X is trivial:

  1. Build GDB (with either gcc or clang)
  2. Code sign it:

     codesign -s gdb-cert gdb

  3. Use this gdb to debug any executable (including just "hello world")
  4. Run the program with "run"
  5. Run it again with "run".

You should see this:

    (XXXXX) malloc: *** error for object 0x10045b570: pointer being freed was
not allocated
*** set a breakpoint in malloc_error_break to debug

Here is the stack trace at the point of error:

Breakpoint 1, 0x00007fff8c8786c0 in malloc_error_break () from i386:x86-64
(gdb) bt
#0  0x00007fff8c8786c0 in malloc_error_break () from i386:x86-64
#1  0x00007fff8c878805 in free () from i386:x86-64
#2  0x00000001002ef4d3 in xfree (ptr=0x10045b570) at
./common/common-utils.c:107
#3  0x00000001001d6d12 in gdb_bfd_unref (abfd=0x103531440) at objfiles.c:1557
#4  0x00000001001d69b8 in free_objfile (objfile=0x1076cca00) at objfiles.c:597
#5  0x00000001001d7c98 in objfile_purge_solibs () at objfiles.c:986
#6  0x0000000100022ec9 in no_shared_libraries (ignored=0x0, from_tty=1) at
solib.c:1205
#7  0x00000001001c1677 in target_pre_inferior (from_tty=1) at target.c:2479
#8  0x000000010016d282 in run_command_1 (args=0x0, from_tty=1,
tbreak_at_main=0) at infcmd.c:516
#9  0x000000010016cb50 in run_command (args=0x0, from_tty=1) at infcmd.c:620
#10 0x0000000100069e3e in do_cfunc (c=0x100a40390, args=0x0, from_tty=1) at
./cli/cli-decode.c:67
#11 0x000000010006decc in cmd_func (cmd=0x100a40390, args=0x0, from_tty=1)
    at ./cli/cli-decode.c:1810
#12 0x00000001002b03e9 in execute_command (p=0x100a0a213 "", from_tty=1) at
top.c:441
#13 0x0000000100199ed9 in command_handler (command=0x100a0a210 "") at
event-top.c:435
#14 0x0000000100199d74 in command_line_handler (rl=0x10353a5b0 "") at
event-top.c:636
#15 0x0000000100314b7a in rl_callback_read_char () at callback.c:220
#16 0x0000000100199561 in rl_callback_read_char_wrapper (client_data=0x0) at
event-top.c:169
---Type <return> to continue, or q <return> to quit---
#17 0x0000000100198bca in stdin_event_handler (error=0, client_data=0x0) at
event-top.c:375
#18 0x00000001001984f9 in handle_file_event (data=...) at event-loop.c:827
#19 0x00000001001968bc in process_event () at event-loop.c:401
#20 0x0000000100196781 in gdb_do_one_event () at event-loop.c:465
#21 0x00000001001970ac in start_event_loop () at event-loop.c:490
#22 0x00000001001985d8 in cli_command_loop () at event-top.c:182
#23 0x000000010018e106 in current_interp_command_loop () at interps.c:309
#24 0x00000001001903de in captured_command_loop (data=0x0) at ./main.c:232
#25 0x000000010018d0c5 in catch_errors (func=0x1001903c0
<captured_command_loop>, func_args=0x0, 
    errstring=0x10040efea "", mask=6) at exceptions.c:502
#26 0x000000010018fe7e in captured_main (data=0x7fff5fbff5a0) at ./main.c:942
#27 0x000000010018d0c5 in catch_errors (func=0x10018ea70 <captured_main>, 
    func_args=0x7fff5fbff5a0, errstring=0x10040efea "", mask=6) at
exceptions.c:502
#28 0x000000010018ea5d in gdb_main (args=0x7fff5fbff5a0) at ./main.c:951
#29 0x0000000100000dbc in main (argc=1, argv=0x7fff5fbff5f8) at gdb.c:34

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[johnw at boostpro dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

John Wiegley <johnw at boostpro dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P1
           Severity|normal                      |critical

--- Comment #1 from John Wiegley <johnw at boostpro dot com> 2012-06-24 23:51:24 UTC ---
I'm upgrading this to P1/critical because it makes GDB completely unusable on
Mac OS X.  I commented out the call to xfree() so I can at least use the
debugger in the meantime.

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com

--- Comment #2 from Tom Tromey <tromey at redhat dot com> 2012-07-31 04:46:54 UTC ---
Can you try cvs trunk gdb?
This area has changed a lot recently.

Otherwise, it would be most useful to know where the BFD in
question was allocated.

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[davidbalbert at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

David Albert <davidbalbert at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davidbalbert at gmail dot
                   |                            |com

--- Comment #3 from David Albert <davidbalbert at gmail dot com> 2012-11-19 04:43:41 UTC ---
I've run into what I think is the same bug in today's trunk. My steps to
reproduce are the same. I'm running OS X 10.8.2. I've included a debugging
session where I reproduce the bug and print a backtrace.

It's interesting that this bug is marked 7.4. I'm not sure if that was a
mistake or not. There was a similar bug
(http://sourceware.org/bugzilla/show_bug.cgi?id=13619) in 7.4 that got fixed in
7.5, but it was reported and fixed quite a few months before this bug, so I
assume they're not duplicates.

At any rate, I can confirm that this bug does not exist in 7.5 but exists in
trunk. Let me know if there's anything else I can do to help.

$ gdb -x gdb-gdb.gdb ./gdb
GNU gdb 6.3.50-20050815 (Apple version gdb-1822) (Sun Aug  5 03:00:42 UTC 2012)
Copyright 2004 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-apple-darwin"...Reading symbols for shared
libraries ...... done

Setting up the environment for debugging gdb.
Breakpoint 1 at 0x100304829: file utils.c, line 934.
Breakpoint 2 at 0x100082211: file cli-cmds.c, line 223.
(top-gdb) run /tmp/gdbtest/hello
Starting program: /Users/david/Development/gdb/build/gdb/gdb /tmp/gdbtest/hello
Reading symbols for shared libraries +++++............................. done
GNU gdb (GDB) 7.5.50.20121118-cvs
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-darwin12.2.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /private/tmp/gdbtest/hello...Reading symbols from
/private/tmp/gdbtest/hello.dSYM/Contents/Resources/DWARF/hello...done.
done.
(gdb) run
Starting program: /private/tmp/gdbtest/hello 
Hello, world
[Inferior 1 (process 95368) exited normally]
(gdb) run

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00000001001dcccd in gdb_bfd_unref (abfd=0x10097b580) at gdb_bfd.c:291
291      gdb_assert (gdata->refc >= 1);
(top-gdb) bt
#0  0x00000001001dcccd in gdb_bfd_unref (abfd=0x10097b580) at gdb_bfd.c:291
#1  0x0000000100201bf9 in free_objfile (objfile=0x10123b400) at objfiles.c:630
#2  0x00000001002031de in objfile_purge_solibs () at objfiles.c:1025
#3  0x0000000100328ee9 in no_shared_libraries (ignored=0x0, from_tty=1) at
solib.c:1206
#4  0x00000001001eac88 in target_pre_inferior (from_tty=1) at target.c:2502
#5  0x0000000100181536 in run_command_1 (args=0x0, from_tty=1,
tbreak_at_main=0) at infcmd.c:541
#6  0x0000000100181867 in run_command (args=0x0, from_tty=1) at infcmd.c:645
#7  0x000000010007947c in do_cfunc (c=0x1009457a0, args=0x0, from_tty=1) at
cli-decode.c:114
#8  0x000000010007def7 in cmd_func (cmd=0x1009457a0, args=0x0, from_tty=1) at
cli-decode.c:1846
#9  0x0000000100300343 in execute_command (p=0x100903c53 "", from_tty=1) at
top.c:486
#10 0x00000001001b7552 in command_handler (command=0x100903c50 "") at
event-top.c:429
#11 0x00000001001b7d53 in command_line_handler (rl=0x100985050 "") at
event-top.c:630
#12 0x0000000100378579 in rl_callback_read_char () at callback.c:220
#13 0x00000001001b6ca1 in rl_callback_read_char_wrapper (client_data=0x0) at
event-top.c:163
#14 0x00000001001b7407 in stdin_event_handler (error=0, client_data=0x0) at
event-top.c:369
#15 0x00000001001b5aca in handle_file_event (data={ptr = 0x7fff00000000,
integer = 0}) at event-loop.c:827
#16 0x00000001001b4eae in process_event () at event-loop.c:401
#17 0x00000001001b4fad in gdb_do_one_event () at event-loop.c:465
#18 0x00000001001b5022 in start_event_loop () at event-loop.c:490
#19 0x00000001001b6ceb in cli_command_loop () at event-top.c:176
#20 0x00000001001aaaca in current_interp_command_loop () at interps.c:332
#21 0x00000001001abc4e in captured_command_loop (data=0x0) at main.c:256
#22 0x00000001001a914a in catch_errors (func=0x1001abc30
<captured_command_loop>, func_args=0x0, errstring=0x1004b01b0 "", mask=6) at
exceptions.c:546
#23 0x00000001001ad46a in captured_main (data=0x7fff5fbff740) at main.c:1032
#24 0x00000001001a914a in catch_errors (func=0x1001abcb0 <captured_main>,
func_args=0x7fff5fbff740, errstring=0x1004b01b0 "", mask=6) at exceptions.c:546
#25 0x00000001001ad9c4 in gdb_main (args=0x7fff5fbff740) at main.c:1041
#26 0x00000001000013e3 in main (argc=2, argv=0x7fff5fbff7a0) at gdb.c:34

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

--- Comment #4 from Tom Tromey <tromey at redhat dot com> 2012-11-19 14:55:39 UTC ---
(In reply to comment #3)

> At any rate, I can confirm that this bug does not exist in 7.5 but exists in
> trunk. Let me know if there's anything else I can do to help.

> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
> 0x00000001001dcccd in gdb_bfd_unref (abfd=0x10097b580) at gdb_bfd.c:291
> 291      gdb_assert (gdata->refc >= 1);
> (top-gdb) bt
> #0  0x00000001001dcccd in gdb_bfd_unref (abfd=0x10097b580) at gdb_bfd.c:291

This may mean that a BFD was opened but not registered with gdb's
BFD reference counter.

I think the most useful bit of information would be to find out where
this BFD is created.  With that I think I could write a patch that you
could test.

I don't have access to Mac OS so I can't do this myself.

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[davidbalbert at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

--- Comment #5 from David Albert <davidbalbert at gmail dot com> 2012-11-22 02:46:50 UTC ---
Created attachment 6752
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6752
A patch fixing the crash

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[davidbalbert at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

--- Comment #6 from David Albert <davidbalbert at gmail dot com> 2012-11-22 02:47:30 UTC ---
I did some poking around and found the location where the offending BFD was
opened. I've included the backtrace below. Here's what I think is happening:

1) darwin_bfd_open calls solib_bfd_fopen, which returns a BFD that has been
registered with gdb's reference counter.

2) darwin_bfd_open then calls bfd_mach_o_fat_extract with the BFD, which may
return the same BFD if it's the proper library for our architecture, or may
return a different BFD if our original BFD is a fat (multi-architecture)
archive. If a new BFD is returned, it needs to be reference counted, but it's
currently not. I've attached a patch that fixes the issue for me, but I'm not
sure if it's in the right place or if there's more to be done. For instance, I
thought it might be necessary to unref the old BFD along with refing the new
one, but unrefing the old one causes a segfault. I'm also not sure if I'm
fixing the bug in the right place.

Breakpoint 3, _bfd_new_bfd () at opncls.c:63
63      nbfd = (bfd *) bfd_zmalloc (sizeof (bfd));
(top-gdb) bt
#0  _bfd_new_bfd () at opncls.c:63
#1  0x00000001003ace61 in _bfd_new_bfd_contained_in (obfd=0x10097b3c0) at
opncls.c:119
#2  0x00000001003dfd2d in bfd_mach_o_fat_extract (abfd=0x10097b3c0,
format=bfd_object, arch=0x10063d2a0) at mach-o.c:4487
#3  0x0000000100028da1 in darwin_bfd_open (pathname=0x10097b2c0
"/usr/lib/libSystem.B.dylib") at solib-darwin.c:517
#4  0x0000000100326278 in solib_map_sections (so=0x101058400) at solib.c:459
#5  0x0000000100326da1 in update_solib_list (from_tty=0, target=0x100640420) at
solib.c:801
#6  0x000000010032756b in solib_add (pattern=0x0, from_tty=0,
target=0x100640420, readsyms=1) at solib.c:886
#7  0x00000001000ed9cb in handle_solib_event () at breakpoint.c:5342
#8  0x00000001000ed685 in bpstat_stop_status (aspace=0x10096a8f0,
bp_addr=140734799861477, ws=0x7fff5fbfee68, ptid={pid = 40646, lwp = 0, tid =
6147}) at breakpoint.c:5232
#9  0x000000010018f6e8 in handle_inferior_event (ecs=0x7fff5fbfee48) at
infrun.c:4205
#10 0x000000010018bcc2 in wait_for_inferior () at infrun.c:2734
#11 0x000000010018abeb in proceed (addr=140734799810600, siggnal=GDB_SIGNAL_0,
step=0) at infrun.c:2315
#12 0x0000000100180d4e in run_command_1 (args=0x0, from_tty=1,
tbreak_at_main=0) at infcmd.c:635
#13 0x0000000100180d97 in run_command (args=0x0, from_tty=1) at infcmd.c:645
#14 0x0000000100078aac in do_cfunc (c=0x1009457a0, args=0x0, from_tty=1) at
cli-decode.c:114
#15 0x000000010007d537 in cmd_func (cmd=0x1009457a0, args=0x0, from_tty=1) at
cli-decode.c:1847
#16 0x00000001002ff413 in execute_command (p=0x100903c53 "", from_tty=1) at
top.c:486
#17 0x00000001001b6a62 in command_handler (command=0x100903c50 "") at
event-top.c:429
#18 0x00000001001b7263 in command_line_handler (rl=0x100977670 "") at
event-top.c:630
#19 0x0000000100377639 in rl_callback_read_char () at callback.c:220
#20 0x00000001001b61b1 in rl_callback_read_char_wrapper (client_data=0x0) at
event-top.c:163
#21 0x00000001001b6917 in stdin_event_handler (error=0, client_data=0x0) at
event-top.c:369
#22 0x00000001001b4fda in handle_file_event (data={ptr = 0x7fff00000000,
integer = 0}) at event-loop.c:827
#23 0x00000001001b43be in process_event () at event-loop.c:401
#24 0x00000001001b44bd in gdb_do_one_event () at event-loop.c:465
#25 0x00000001001b4532 in start_event_loop () at event-loop.c:490
#26 0x00000001001b61fb in cli_command_loop () at event-top.c:176
#27 0x00000001001a9fda in current_interp_command_loop () at interps.c:332
#28 0x00000001001ab15e in captured_command_loop (data=0x0) at main.c:256
#29 0x00000001001a866a in catch_errors (func=0x1001ab140
<captured_command_loop>, func_args=0x0, errstring=0x1004af240 "", mask=6) at
exceptions.c:546
#30 0x00000001001ac97a in captured_main (data=0x7fff5fbff710) at main.c:1032
#31 0x00000001001a866a in catch_errors (func=0x1001ab1c0 <captured_main>,
func_args=0x7fff5fbff710, errstring=0x1004af240 "", mask=6) at exceptions.c:546
#32 0x00000001001aced4 in gdb_main (args=0x7fff5fbff710) at main.c:1041
#33 0x0000000100000a13 in main (argc=2, argv=0x7fff5fbff778) at gdb.c:34

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

--- Comment #7 from Tom Tromey <tromey at redhat dot com> 2012-11-27 15:47:29 UTC ---
Thanks for the analysis.

For submitting patches see:
http://sourceware.org/gdb/contribute/

I read this patch and I think it may still have problems,
although it is definitely an improvement over the status quo.

First, darwin_bfd_open leaks 'abfd'.
Second, if we close 'abfd' then the dependent BFD probably breaks.

One approach would be to write a wrapper for bfd_mach_o_fat_extract
along the lines of gdb_bfd_openr_next_archived_file.

I'll upload a patch shortly.  I'd appreciate it if you could try
it out and see whether it fixes your problem.

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #6752|0                           |1
        is obsolete|                            |

--- Comment #8 from Tom Tromey <tromey at redhat dot com> 2012-11-27 15:49:04 UTC ---
Created attachment 6758
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6758
proposed patch

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[davidbalbert at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

--- Comment #9 from David Albert <davidbalbert at gmail dot com> 2012-11-27 17:39:22 UTC ---
The patch works for me (I applied it on top of the latest trunk).

One question: on line 94 of the patch, is it necessary to call gdb_bfd_ref on
`result`?  In this case, bfd_mach_o_fat_extract was basically a noop, and
`abfd` was already reference counted by solib_bfd_open.

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

--- Comment #10 from Tom Tromey <tromey at redhat dot com> 2012-11-27 17:46:09 UTC ---
(In reply to comment #9)
> The patch works for me (I applied it on top of the latest trunk).
> 
> One question: on line 94 of the patch, is it necessary to call gdb_bfd_ref on
> `result`?  In this case, bfd_mach_o_fat_extract was basically a noop, and
> `abfd` was already reference counted by solib_bfd_open.

Thanks for the note -- you are right, the current patch is funny here.
My intent was for gdb_bfd_mach_o_fat_extract to always return a new
reference so that the result could be handled uniformly in all cases.
However I forgot a decref in darwin_bfd_open.
I'll upload a new patch that fixes this.

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #6758|0                           |1
        is obsolete|                            |

--- Comment #11 from Tom Tromey <tromey at redhat dot com> 2012-11-27 17:47:44 UTC ---
Created attachment 6759
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6759
patch with added decref

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[davidbalbert at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

--- Comment #12 from David Albert <davidbalbert at gmail dot com> 2012-11-27 19:28:56 UTC ---
Ah, I see what your plan was. The new patch works for me and it doesn't have
any more issues that I can see. There were clearly some pieces of understanding
(gdata->archive_bfd, etc) that I was missing when I wrote mine. Thanks for
writing it!

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[cvs-commit at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

--- Comment #13 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> 2012-11-28 18:48:44 UTC ---
CVSROOT:    /cvs/src
Module name:    src
Changes by:    tromey@sourceware.org    2012-11-28 18:48:38

Modified files:
    gdb            : ChangeLog gdb_bfd.c gdb_bfd.h solib-darwin.c 

Log message:
    PR gdb/14290:
    * solib-darwin.c (gdb_bfd_mach_o_fat_extract): New function.
    (darwin_solib_get_all_image_info_addr_at_init, darwin_bfd_open):
    Use it.
    * gdb_bfd.h (gdb_bfd_mark_parent): Declare.
    * gdb_bfd.c (gdb_bfd_mark_parent): New function.
    (gdb_bfd_openr_next_archived_file): Use it.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.14863&r2=1.14864
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/gdb_bfd.c.diff?cvsroot=src&r1=1.13&r2=1.14
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/gdb_bfd.h.diff?cvsroot=src&r1=1.7&r2=1.8
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/solib-darwin.c.diff?cvsroot=src&r1=1.32&r2=1.33

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |7.6

--- Comment #14 from Tom Tromey <tromey at redhat dot com> 2012-11-28 18:50:18 UTC ---
Fixed on trunk but probably still broken in 7.5.

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[davidbalbert at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

--- Comment #15 from David Albert <davidbalbert at gmail dot com> 2012-11-28 19:36:20 UTC ---
I can confirm that this bug no longer present in trunk.

I checked the 7.5 branch from the git mirror and the 7.5 release from August
and neither of them appear to have this bug. I didn't try to figure out why
because everything seems to work.

-- 
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.

[Bug gdb/14290] gdb_bfd_unref frees an already freed memory block

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14290

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|7.6                         |7.5

--- Comment #16 from Tom Tromey <tromey at redhat dot com> 2012-11-28 20:22:27 UTC ---
Thanks for trying 7.5.  Marking as fixed.

-- 
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.