[Gc] Occasionally crash with GraphicsMagick, ImageMagick.
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.
> -----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: [Gc] Occasionally crash with GraphicsMagick,
> 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
More information about the Gc