Tommy Vercetti schrieb:

I don't know what's "refrubish rate" of gc, but I would say that any garbage collector is a pretty much cause of solid leak of memory (unless it frees memory when not used anymore, but I doubt they do).




gcc gc does free memory when it has not been used in the last 2 collections. on a normal termination there are still gc roots so there are still pages allocated, but I've done a collection with no roots and GC says 0k allocated, and there's still a leak.

it must come from another part of gcc. there is a pool allocator, but it is not used at all(at least when compiling c++).

would it help to do leak checking on libiberty alloc functions or is than done regularily anyway?


-- Stefan Strasser

Reply via email to