Garbage collector bug

I have written a program in ANSI C that is supposed to work under any
platform and for any C compiler. After checking that it does work under
Windows and various UNIX system, I released it. Than I got a report that it
doesn't work properly when compiled using gcc, which uses built-in garbage
collector.

After some investigation, I understood that there happened the following
problem :

At some stage of program's running there where 2 memory blocks A and B, A
holding pointers to B.

Than A was reallocated : A = realloc(A,...). 
A was copied to another location holding the same data and the same pointers
to B.
But, the data in B have changed! It shouldn't have happened and it doesn't
happen with other compilers.  
I suspect, that the garbage collector thinks that nobody points to B while A
is being reallocated and frees B. 

Regards,
Nadel Alexander
NDS
phone : 02-5894632
fax : 02-5894825

__________________________________________________________ 
Information contained in this email message is intended only for use of the
individual or entity named above. If the reader of this message is not the
intended recipient, or the employee or agent responsible to deliver it to

RE: Garbage collector bug

Is this really using our garbage collector?

Gcc uses garbage collectors in three very different ways:

1) The compiler itself has its own internal garbage collector.  If this fails, the most likely symptom is a
compiler crash.  It is also conceivable that gcc may generate incorrect code.  This garbage collector is
not part of the generated executable.  It only handles the compilers internal tree representation of the
program.  I don't think this collector is relevant here, and it's not the subject of this mailing list.

2) It uses a variant of our collector in the Java (gcj) run-time.  But we're dealing with a C program here.

3) I believe there is a way to have Objective C programs use our collector, but I'm not very familiar with the
details.  Last I heard, this required you to install a separate copy of the collector, not the one in the gcc tree.

It's certainly possible to use our collector with a C program, but you have to do so quite explicitly.  If this
is what's being done, then it would be useful if you could reduce the problem to a small test case. 
Alternatively, there are hints for debugging this sort of problem near the end of

http://www.hpl.hp.com/personal/Hans_Boehm/gc/debugging.html

Hans

> -----Original Message-----
> From: Nadel, Alexander [mailto:ANadel@...]
> Sent: Wednesday, January 08, 2003 9:24 AM
> To: 'Hans_Boehm@...'
> Cc: 'gc@...'
> Subject: Garbage collector bug
> 
> 

Re: Garbage collector bug

On 08-Jan-2003, Nadel, Alexander <ANadel@...> wrote:
> 
> I have written a program in ANSI C that is supposed to work under any
> platform and for any C compiler. After checking that it does work under
> Windows and various UNIX system, I released it. Than I got a report that it
> doesn't work properly when compiled using gcc, which uses built-in garbage
> collector.

First principle of bug reports: always say which OS you are using,
and exactly which version of all of the programs involved is being used
(e.g. which version of gcc, and which version of the GC, if there is a
GC involved).

> After some investigation, I understood that there happened the following
> problem :
> 
> At some stage of program's running there where 2 memory blocks A and B, A
> holding pointers to B.
> 
> Than A was reallocated : A = realloc(A,...). 
> A was copied to another location holding the same data and the same pointers
> to B.
> But, the data in B have changed! It shouldn't have happened and it doesn't
> happen with other compilers.  

Probably there is a bug in your program.  As Hans explained, gcc doesn't
link C programs with a garbage collector by default.  So it seems very
unlikely that there is any garbage collector involved here.

The fact that your program works on some systems doesn't mean that it

gc and tracking memory usage

I am currently porting a simulator from a custom memory allocator to the 
garbage collector.  One of the features of the old allocator was the 
concept of memory ids.  You could pass an id to new and delete, and it 
would keep track of how much memory you had allocated and freed under 
that id for debugging purposes.

I'd like to keep that accounting aspect of the old allocator, while using 
gc under the hood.  The only way I can see to do this is to add 
finalization code to update the statistics.  I've read the material on the 
website about finalization with cyclic structures, and I'm wondering if 
there is any way to maintain the amount freed correctly.  Thank you in 
advance.

--

-- 
Francesco Spadini
http://www.crhc.uiuc.edu/~spadini
spadini@...

"The universe is full of magical 
things, patiently waiting for our 
wits to grow sharper."
	- Eden Phillpots

Question about two-level tree

I have been studying the data structures used by the GC, and I'm
puzzled about the two-level tree that's used to find the start of an
object given an interior pointer.  Why is it a good idea to describe
large objects by giving a displacement to the beginning of the object,
rather than having all the entries for the object point to a single
block header for the whole object?  It seems to me that the
displacement idea is just a more complicated way of finding the same
header.

-- Mike

RE: Question about two-level tree

IIRC, there is no strong argument for the current approach.  What you suggested is probably simpler.  It may
or may not be faster.

I think the performance tradeoff isn't completely clear one way or the other.  If several entries map to the
same block header, you would have to look up the block starting address in the header, or something along
those lines.  That would add some overhead.  And you'd have to be careful that it didn't add overhead to the
common case (which probaby occurs 99.999% of the time), in which the pointer references the first page of a block.

This was never changed, mostly because the comparison with the other technique was never done, and I
suspect it doesn't make much difference either way.

Hans

-----Original Message-----
From: Mike Spivey
To: gc@...
Sent: 1/16/03 10:37 AM
Subject: [Gc] Question about two-level tree

I have been studying the data structures used by the GC, and I'm
puzzled about the two-level tree that's used to find the start of an
object given an interior pointer.  Why is it a good idea to describe
large objects by giving a displacement to the beginning of the object,
rather than having all the entries for the object point to a single
block header for the whole object?  It seems to me that the
displacement idea is just a more complicated way of finding the same
header.

-- Mike

installation question

I notice that doing a "make install" on the GC sources installs the
libraries but not the include files, which makes it annoying to use (I had
to manually install them).  Can the Makefiles be updated to install the
include files into e.g. /usr/local/include/gc?  I'm using the 6.1 sources.

Mike

RE: installation question

Include file installation should already be fixed in 6.2alpha1, which I just released.  If you still have
problems with this, please let me know.

Hans

> -----Original Message-----
> From: Michael Vanier [mailto:mvanier@...]
> Sent: Thursday, January 23, 2003 5:20 PM
> To: gc@...
> Subject: [Gc] installation question
> 
> 
> 
> I notice that doing a "make install" on the GC sources installs the
> libraries but not the include files, which makes it annoying 
> to use (I had
> to manually install them).  Can the Makefiles be updated to 
> install the
> include files into e.g. /usr/local/include/gc?  I'm using the 
> 6.1 sources.
> 
> Mike
> 
> _______________________________________________
> Gc mailing list
> Gc@...
> http://linux.hpl.hp.com/cgi-bin/mailman/listinfo/gc
> 

Re: installation question

That's what I call a quick fix   Thanks, Hans.

Mike

> From: "Boehm, Hans" <hans_boehm@...>
> Date: Thu, 23 Jan 2003 17:44:59 -0800
> 
> Include file installation should already be fixed in 6.2alpha1, which I just released.  If you still have
problems with this, please let me know.
> 
> Hans
> 
> > -----Original Message-----
> > From: Michael Vanier [mailto:mvanier@...]
> > Sent: Thursday, January 23, 2003 5:20 PM
> > To: gc@...
> > Subject: [Gc] installation question
> > 
> > 
> > 
> > I notice that doing a "make install" on the GC sources installs the
> > libraries but not the include files, which makes it annoying 
> > to use (I had
> > to manually install them).  Can the Makefiles be updated to 
> > install the
> > include files into e.g. /usr/local/include/gc?  I'm using the 
> > 6.1 sources.
> > 
> > Mike
> > 

Which version is for Visual C++ 6.0 Compiler