[Gc] Silently fails to allocate memory?

The Devils Jester thedevilsjester at gmail.com
Sat Apr 13 13:56:32 PDT 2013


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20130413/1c353eb0/attachment.htm


More information about the Gc mailing list