[Gc] Occasionally crash with GraphicsMagick, ImageMagick.

Boehm, Hans hans.boehm at hp.com
Thu Jul 1 17:06:58 PDT 2010


Apologies for digging up an old thread ...

It occurs to me that another possible issue here was calling GC_free on an object with associated debug information added by GC_debug_malloc/GC_MALLOC in debug mode.  However enabling assertions should have caught that.

If you're consistently using the debug routines, GC_FREE should usually catch double frees.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Thursday, May 06, 2010 3:07 AM
> To: gc at napali.hpl.hp.com
> Cc: Shi Jie Gung
> Subject: Re[2]: [Gc] Occasionally crash with GraphicsMagick, 
> ImageMagick.
> 
> 
> Thu, 6 May 2010 21:49:12 +1200 Bruce Hoult <bruce at hoult.org>:
> 
> > On Thu, May 6, 2010 at 9:17 PM, Shi Jie Gung 
> <ksc91u_fr at yahoo.fr> wrote:
> > > So why kernel complain can not access 0x08 but print nhdr 
> says 0x0?
> > >
> > > (gdb) print nhdr->hb_prev
> > > Cannot access memory at address 0x8
> > > (gdb) print nhdr
> > > $3 = (hdr *) 0x0
> > 
> > That is a null pointer, which is not a valid address on any recent 
> > operating system I know of.
> > 
> > You can print nhdr because that is simply printing the 
> value of nhdr 
> > as if it was an integer.  Only "print nhdr->hb_prev" is trying to 
> > actually use it as a memory address.  (So would "print *nhdr").
> > 
> > Hans had suggested that you GC_free()'d a pointer that had been 
> > allocated using malloc().
> > 
> > It looks to me more likely that you have called GC_free() 
> on an object 
> > (which adds it to the start of the free list) and then continued to 
> > use that object elsewhere, overwriting the free list pointer now 
> > contained in it.
> 
> I think the same.
> 
> > 
> > GC_free() is a very dangerous call. Errors in using it (use after 
> > free, double delete) make your program just as unsafe as programs 
> > using malloc/free.
> 
> Well, the collector is in leaks finding mode (which means 
> GC_free must be used for every unused object otherwise there 
> would be a leak).
> The problem is that BoehmGC doesn't help much in detecting 
> double-delete or use-after-free cases.
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 


More information about the Gc mailing list