[Gc] strange problem: GC needs manually calling to GC_gcollect()?

Boehm, Hans hans.boehm at hp.com
Tue Jul 12 14:22:50 PDT 2005


In general, it's dangerous to mix malloc/free and GC_MALLOC, since
the collector does not trace objects allocated with the system malloc.
If a GC_MALLOCed object is referenced only from malloced memory,
it is likely to get garbage collected (and cleared) prematurely.
If you need/want to allocate uncollected objects,
GC_MALLOC_UNCOLLECTABLE
+ GC_FREE are much safer.

It may be that the object was found to be unreachable at the previous
GC because the only reference was in a malloc'ed object.  The object
would only be cleared by the sweep "phase", which is run lazily
and incrementally.  It may run as part of the GC_MALLOC call.

There are some hints about debugging premature object collections
at http://www.hpl.hp.com/personal/Hans_Boehm/gc/debugging.html .

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Zhang Le
> Sent: Tuesday, July 12, 2005 1:39 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] strange problem: GC needs manually calling to 
> GC_gcollect()?
> 
> 
> Hi,
>   I'm trying using GC (6.5) in a C project, and find some problems.
>   My project is a tree search algorithm. GC_MALLOC() is the 
> only GC function besides GC_INIT() used in my program. I also 
> use a hash table and linked list which are managed properly 
> with malloc/free.
>  
>  When running the core routine of my program for many 
> iterations, which involves lots of GC_MALLOC, my program 
> stops at an assertion
> failure:
> 
> test_viterbi: viterbi.c:1873: create_node: Assertion `U1 == 
> parent->U' failed.
> 
> The corresponding code is:
> === code begin ===
> viterbi_tree_node_t* create_node(viterbi_tree_node_t* parent, 
> int state,
>     int L, int order) {
>     int i;
>     viterbi_tree_node_t* node;
>     viterbi_tree_node_t* p1 = parent;
>     double** U1 = 0;
> 
>     if (parent) {
> (1)            U1 = parent->U;
>     }
> 
>   (2)   node = 
> (viterbi_tree_node_t*)GC_MALLOC(sizeof(viterbi_tree_node_t));
>     if (parent)  {
>  (3)      assert(U1 == parent->U);
>         assert(U1);
>         assert(parent->U);
>     }
> ...
> === code end ===
> at (1), I save the U array of node parent in U1.
> then at (2), make a call to GC_MALLOC to allocate a new node 
> But at (3), I find the parent node's U field changes (to 
> zero), which is different from the saved pointer  at (1), and 
> cause an assert failure.
> 
> It's quite strange to me. And it seems during the GC_MALLOC 
> call, GC wrongly clear the memory of the parent node which is 
> allocated by earlier call to this function and is still in use. Why?
> 
> I try to run GC_gcollect(void) every 10 calls to my core 
> routine, and the problem solves. However, the same problem 
> occurs when I run
> GC_gcollect(void) every 30 or more calls to my core routine. 
> My program uses little memory, and I'm sure I'm not running 
> out of memory.
> 
> Any tips?
> 
> Zhang Le
> 
> _______________________________________________
> 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