[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...
More information about the Gc