Darryl Okahata writes:
Jan Vroonhof <vroonhof(a)math.ethz.ch> wrote:
> Darryl Okahata <darrylo(a)sr.hp.com> writes:
>
> > [2 leaks <text/plain; US-ASCII (quoted-printable)>]
> > MLK: 304000 bytes leaked at 0x401bc638
> > * This memory was allocated from:
> > malloc [rtlib.o]
> > xmalloc [alloc.c:390]
> > regex_compile [regex.c:3099]
> > re_compile_pattern [regex.c:5953]
> > compile_pattern_1 [search.c:143]
> > compile_pattern [search.c:186]
> > string_match_1 [search.c:387]
>
> It does look pretty suspect. There is loads of 'passing the pointer
> being done'. How rare are systems without REGEX_MAY_ALLOC? I suspect
> this case is exercised less. However it migth well be that the
> particular rexexp ist just never GCed.
Well, if it is a real memory leak, it's not being caused by
GC.
This particular memory block is part of a non-lisp global variable.
However, I can't find any place where this leak could be caused. I'm
wondering if temacs is zero'ing some global memory before it exit()'s
(in which case this would not be a real leak).
I peeked a little at the code, and from that and some half-remembered
conversation, it seems that we are caching compiled regular
expressions, and dumping the least-recently-used one when the regexp
is not in the cache.
While at first it seems as if we are only overwriting the LRU buffer,
and not actually clearing it, it turns out that deep in the dark
recesses of `regex_compile', it is reusing the buffer anyway.
So the "leak" is most likely just because of the global cache, and not
an actual leak.
I think.
If I have time (which I probably don't), I'll try to
step through
temacs to see where the leak is occurring.
If you could call the functions to have purify report leaks on the
fly, rather than only at exit, that should help a lot.
On the other hand, searching for leaks is expensive. I notice that
there is a -with-quantify compile flag. Maybe I should make a purify
one, and see what happens.
--
Colin