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

Zhang Le 69dbb24b2db3daad932c457cccfd6 at gmail.com
Wed Jul 13 11:07:24 PDT 2005


Thanks for the reply. 

My understanding now is that it is unsafe to store GC_MALLOCed memory
pointer in malloced pointers, unless I change all code to use
GC_MALLOC/GC_FREE.

 I notice on the example page there is a warning statement reads:
"Interaction with the system malloc
It is usually best not to mix garbage-collected allocation with the
system malloc-free. If you do, you need to be careful not to store
pointers to the garbage-collected heap in memory allocated with the
system malloc."

This statement is so technical that I ignored it the first time I read it :-)

I have one more question. Will the memory be collected correctly if I
offset the pointer:
double* p = GC_MALLOC(sizeof(double)*100);
p += 50;
// access p[-10] p[-20], p[30] etc.

Here  I offset p to allow the use of negative  index, and p no longer
points to the original memory address. Will p still be collected?

Zhang Le


On 7/12/05, Boehm, Hans <hans.boehm at hp.com> wrote:
> 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/
> >
> 
> _______________________________________________
> 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