Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Feb 2007 11:21:09 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        Jason Evans <jasone@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, cokane@cokane.org
Subject:   Re: cvs commit: src/lib/libc/stdlib malloc.c
Message-ID:  <200702011121.10651.jhb@freebsd.org>
In-Reply-To: <45C1316C.8010500@FreeBSD.org>
References:  <200701312254.l0VMsKZ6050188@repoman.freebsd.org> <346a80220701311514j6aa9e3eavc5a4de2bffc039d7@mail.gmail.com> <45C1316C.8010500@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 31 January 2007 19:16, Jason Evans wrote:
> Coleman Kane wrote:
> >       Modified files:
> >         lib/libc/stdlib      malloc.c
> >       Log:
> >       Fix a utrace(2)-related bug in calloc(3).
> > 
> >       Integrate various pedantic cleanups.
> > 
> >       Submitted by:   Andrew Doran <ad@netbsd.org <mailto:ad@netbsd.org>>
> > 
> >       Revision  Changes    Path
> >       1.139     +56 -44    src/lib/libc/stdlib/malloc.c
> >     _______________________________________________
> > 
> > Does this fix the following error I get in GDB alot:
> > Assertion failed: (mapelm.free == false), function arena_salloc, file 
> > /usr/src/lib/libc/stdlib/malloc.c, line 2355.
> 
> That assertion failure is likely due to an application bug, specifically 
> a double free.

Yes.  I fixed at least one double free in gdb a while back and sent the patch 
to obrien@ and marcel@ but never heard back.

Here's the original message I sent:

<quote type="email" subject="gdb bug">
Tracked down and fixed a bug in ports/gdb6 at work that we've been running 
into.  It appears to apply to src/contrib/gdb as well.  I assume you all are 
more familiar with gdb internals than I am, but there appears to be this 
target stack of "driver backends" (more or less).  And at the top there is a 
dummy &current_target which is _not_ included in the global target_structs 
list (presumably on purpose).  There is this function that realloc()'s a 
target's to_sections pointer and then goes through and updates all the other 
targets that are using the same pointer.  The problem is that since 
current_target isn't in the global list, &current_target won't get updated if 
it's using the same value that is being realloc'd (the test case at work 
involved debugging apache, which makes heavy use of dlopen() and dlclose()).  
The patch below fixes the problem, and I thought I'd let you 2 see it to see 
if you wanted to do anything with it:

--- gdb/target.c.orig   Mon Aug  2 17:57:26 2004
+++ gdb/target.c        Mon Oct 30 15:07:51 2006
@@ -1415,6 +1415,13 @@
              (*t)->to_sections_end = target->to_sections_end;
            }
        }
+
+      /* JHB: Need to update current_target too. */
+      if (current_target.to_sections == old_value)
+       {
+         current_target.to_sections = target->to_sections;
+         current_target.to_sections_end = target->to_sections_end;
+       }
     }

</quote>

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702011121.10651.jhb>