[Gc] Silently fails to allocate memory?

Brian Beuning bbeuning at corecard.com
Sat Apr 13 18:11:55 PDT 2013

I recently used GC to allocate 2 GB of objects and it worked fine.

I think we get what you are doing and the issue you are seeing.
There are too many things your code might be doing wrong for anyone to guess at.
If you can reproduce the issue with some small test case (under 100 lines)
then someone will probably volunteer to look at it.

----- Original Message -----
From: "The Devils Jester" <thedevilsjester at gmail.com>
To: "Basile Starynkevitch" <basile at starynkevitch.net>
Cc: gc at linux.hpl.hp.com
Sent: Saturday, April 13, 2013 4:56:32 PM
Subject: Re: [Gc] Silently fails to allocate memory?

On Sat, Apr 13, 2013 at 3:24 PM, Basile Starynkevitch < basile at starynkevitch.net > wrote: 

Also, if you have a working, GC-less, variant of your program (malloc based, or new+delete based), be sure 
to test with valgrind that it does not leak memory. 

I may not be explaining my situation well enough. I never use delete on the objects that inherit from gc. When I disable libgc, these objects are never freed (I do not replace libgc with manual delete calls). Which is why I say its unlikely that its a out of memory issue when libgc is enabled, because when I disable libgc, there is as much, or more, un-deleted memory being created. Although if I keep libgc in the mix, and delete where I can (I can only do this in a limited controlled test, not in actual real world situations) then it also works fine. 

I use libgc because it would be very difficult to keep track of certain objects to know when it should delete them. As such it would be very difficult to implement a non libgc test that satisfies valgrind. 

I know that when libgc "fails", it is definitely memory (quantity) based, since if I create more objects in the big loop, it fails faster, but the majority of the objects are classes that are not much more than a couple primitive C types (so I should be able to create more than a few thousand). I am working on narrowing down exactly what happens, but finding such issues when memory is involved is no easy task. 

Gc mailing list
Gc at linux.hpl.hp.com

More information about the Gc mailing list