Re: [BUG] Tremendous memory leak
Some time ago, Kyle Jones wrote...
Kirill 'Big K' Katsnelson writes:
> Ok, I tested it with the NT allocator. There is a memory leakage,
> but it's different. Anybody knows what's that?
This is probably not a memory leak. Under UNIX you can't always
give memory back to the system, either because malloc() doens't
know that the memory it is all freed or because malloc() doesn't
know all the pointers that point to a block of used memory so
that relocation can be done. Test results vary depending on how
clever malloc() is.
That was what I thought in the first place, this is why I re-tested
it under NT allocator. I understand that malloc'ed memory cannot
be moved, and that free shots holes which could not always be reused,
when requested new allocation does not fit into any hole, in which
case sbrk is used to extend the heap.
Now it looks like any of the two (or both in the worst case) lose:
either emulated sbrk() in XEmacs (it is in ntheap.c, there is no
real one), or the galloc allocator.
My test is kind of artificial, but it shows that there can be
conditions under which XEmacs tends to devour memory indefinitely.
I just want to be sure that if the cause of the problem is the
gnu allocator, then it will be fixed.
One possible enhancement to the allocation scheme is to allocate
very large blocks of memory using system virtual memory allocator.
Regular heap managers are not designed for whopping big memory blocks.
Big K