From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7583 invoked by alias); 22 Nov 2012 02:47:32 -0000 Received: (qmail 7563 invoked by uid 48); 22 Nov 2012 02:47:31 -0000 From: "davidbalbert at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/14290] gdb_bfd_unref frees an already freed memory block Date: Thu, 22 Nov 2012 02:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: davidbalbert at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2012-q4/txt/msg00301.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14290 --- Comment #6 from David Albert 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 , 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 , 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.