[Gc] Silently fails to allocate memory?
bruce at hoult.org
Fri Apr 12 22:55:31 PDT 2013
On Sat, Apr 13, 2013 at 2:43 PM, The Devils Jester <
thedevilsjester at gmail.com> wrote:
> If, for example, I am not deleting something because it was in the
> destructor, would not the worse case scenario be unfreed memory? What
> could cause libgc to "give up" on Linux (but not apparently on OSX)? This
> is not actually the case though (I dont do anything in destructors).
It shouldn't "give up". I've never seen such a thing. And you don't
describe what you mean by "give up" or "silently fail". Does it return a
If all you are doing is allocating memory then unfreed memory is the worst
that can happen. If you were relying on C++ destructors to close files then
you could run out of file handles.Or similar for other resources.
> If my object has a vector of pointers, would not those be automatically
> collected as well?
Of course, if those pointers were to memory allocated by GC and there are
no other live pointers to those objects. And if the memory for the vector
itself has been allocated by GC.
> The question is not about it working or not (I believe it is) its about
> any call to new silently failing after a certain number of objects
> created. (Which as I said works fine if I manually call delete or I
> disable libgc.)
> What could I be doing wrong that would cause something like this? All I
> am doing is using gc inherited objects, with the new command. Is C++11 or
> certain compiler flags an issue? (Just O2 iirc).
With your talk about "vectors" I wonder whether you are in fact doing
something like storing the pointers to your GC-allocated objects (only) in
an STL vector which is using ordinary malloc() allocated memory
internally.. In which case as far as the GC is concerned there is no
pointer to your objects and the memory will be reused for new objects.
In that case when you allocate a new object the address will be the same an
for an object that you allocated earlier, and still think you are using.
> On Apr 12, 2013 9:03 PM, "Bruce Hoult" <bruce at hoult.org> wrote:
>> The GC does actually work, and thousands of programs (and indeed
>> products) use it, so the most likely explanation is that you're doing
>> something wrong. Unfortunately we have no way of knowing without seeing
>> your code.
>> You're aware that C++ destructors won't be called by the GC? They're not
>> needed if all they'd do is free other memory that is also GC allocated, but
>> they will be if you need to close files or free other memory, such as that
>> allocated using malloc by library code (including the STL). In that case
>> you need to register finalizers for the affected objects.
>> On Sat, Apr 13, 2013 at 9:51 AM, The Devils Jester <
>> thedevilsjester at gmail.com> wrote:
>>> It is difficult to describe the issue I am having with libgc.
>>> I have a for loop that allocates thousands of (small) objects. Each
>>> iteration of the loop only allocates a few new objects, but when the loop
>>> is sufficiently large (usually around 3500 iterations), then for some
>>> reason it just...well gives up. It does not hang or segfault, or give any
>>> indication that something is wrong, but it (and this is difficult to
>>> determine) seems to silently stop allowing the objects to be created.
>>> If I disable libgc (or manually call delete, which is not a working long
>>> term solution), the loop executes correctly. This is on Ubuntu Linux using
>>> GCC 4.7 .
>>> On Mac OS X, I cannot tell if its working (which it appears to be) or if
>>> the limit to "give up" is might higher.
>>> Is there some trick to this? Am I using it wrong? How I am using libgc
>>> is by simply including "gc_cpp.h" calling "GC_INIT" and having my class(es)
>>> inherit from gc.
>>> This message has been scanned for viruses and
>>> dangerous content by *MailScanner* <https://www.mailscanner.info/>, and
>>> believed to be clean.
>>> Gc mailing list
>>> Gc at linux.hpl.hp.com
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <https://www.mailscanner.info/>, and is
> believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gc