[Gc] Crash in GC_realloc - HDR(h) NULL

Boehm, Hans hans.boehm at hp.com
Fri Aug 22 10:30:55 PDT 2008



> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Emmeran Seehuber
> Sent: Friday, August 22, 2008 4:33 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Crash in GC_realloc - HDR(h) NULL
>
> Hi,
>
> I`m using the GC 7.1cvs (head) and get a very rare crash in
> GC_realloc(). The program crashes when accessing hhdr at the
> beginning of GC_realloc():
>
> hhdr = HDR(h);
> sz = hhdr -> hb_sz;
>
> hddr is NULL here. In which cases can HDR(h) return NULL?
That should mean that h is not in the garbage-collected heap.

>
> The old pointer given to GC_realloc() looks fine (contains
> valid data). I don`t think this is a bug in the GC, but
> rather my program might have corrupted some GC memory. Since
> I explicit control the collections (i.e. with
> GC_disable()/GC_enable(), collection only in the mainthread)
> and log each collector run into the debug console I can tell
> you that the collector did not run for at least 300 seconds,
> so it should be not a problem with premature collection of memory.
>
> I`ve got this problem on Win32 (in some Win32 specific
> network code), i did not yet encounter it on Linux x86. The
> application is multithreaded, does not use TLS-Allocator,
> does not use incremential collection, every thread starts
> running with GC_call_with_stack_base(),
> GC_MALLOC_ATOMIC_IGNORE_OFF_PAGE() is used when ever
> possible, and GC_malloc_explicitly_typed() is used in most
> other cases. Memory is freed using GC_FREE() when ever
> possible (i.e. the lifetime of the memory is exactly known).
> The memory passed to GC_realloc() is allocated using
> GC_MALLOC(). The collector is built without Debug using a
> patched gc.mak with Visual Studio 2005 using the following options:
>
> CPP_PROJ=/nologo /MDd /W3 /Gm /EHs-c- /GS- /GL /Zi /O2 /I
> include \  /D "NDEBUG" /D "GC_BUILD"\  /D "WIN32" /D
> "_WINDOWS" /D "LARGE_CONFIG" /D "ALL_INTERIOR_POINTERS" \  /D
> "__STDC__" /D\  "GC_WIN32_THREADS"  /FR"$(INTDIR)/"
> /Fp"$(INTDIR)/gc.pch" /wd4996 \  /Fo"$(INTDIR)/"\
> /Fd"$(INTDIR)/" /I "libatomic_ops-1.2\src" /c
>
> In 99% everything works fine. Only in rare cases I get this
> crash. Any hint how I could get the reason for this crash?
My first suspicion would be that the object being reallocated is in fact not allocated with GC_MALLOC, but through some other means.  It would be good to check at the allocation site that this is in fact the pointer returned by the GC_MALLOC call, and that GC_find_header(returned pointer) gives you a non-null pointer to the block header at that point.

If that's OK, there's a more remote chance that the block containing the object has been entirely reclaimed, because the pointer was hidden from the collector, or the object was previously explcitly deallocated.  But in that case, I'd be surprised that you're only seeing this particular failure.  How large is the object that's involved here?

And of course there's always the possibility of a GC bug.

Hans
>
> Thanks.
>
> Emmeran Seehuber
>



More information about the Gc mailing list