bug#9221: Memory leak

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 01 Aug 2011 22:23:18 -0400
> 
> I'm seeing some weird behavior linked to insane memory consumption.
> E.g. my Gnus session tends to grow to more than 2GB and then become
> unusage and unkillable (or close enough: in D state, "kill -9" isn't
> enough to make it stop use CPU, tho I guess that CPU use is really due
> to something like the OS being in the process of dumping the core file,
> tho I don't see any left over core files).

Does anyone else see similar memory footprint growth?

> I did manage to attach to it and get a few backtraces (with
> a breakpoint on mmap) before it was too late, and bidi_shelve_cache
> showed up in most of the backtraces (like 5 out of 8, maybe): not
> a strong indictment, but at least a lead worth following until I get
> more data.

bidi_shelve_cache is used extensively during redisplay, and it does
allocate memory (which should be almost immediately freed by its
companion bidi_unshelve_cache, or by an explicit xfree call in a few
places).  So the fact that you saw it on the callstack of a breakpoint
in mmap is what I'd expect, not really an evidence of a leak.  To see
if the leak is really due to bidi, run a session with
bidi-display-reordering turned off, and see if there's any change.
Although, AFAIR, some calls to bidi_shelve_cache are not conditioned
on bidi.

FWIW, I'm running a session continuously for several days since the
last rebuild, and don't see any unusual footprint, let alone one that
grows without limits.  But that's a with a code base that is slightly
different from the trunk, and I don't use Gnus, so perhaps some change
done lately (including in bidi.c) is responsible.  What trunk revision
are you running.

If we cannot exclude bidi_shelve_cache from the list of suspects, I
could add debugging code that monitored its allocations and
deallocations.  That would allow us to see if there's non-zero
balance.