On Mon, 03 Nov 2003 20:27:34 +0100
Hrvoje Niksic <hniksic(a)xemacs.org> wrote:
junq <junq(a)ihubbell.com> writes:
>> It might well be, but it's far from obvious where the problem lies.
>>
>> Does the leak occur if you start `xemacs -q', load a Perl script,
>> and leave XEmacs for the night?
>
> Don't know, but tonight I will do that and report my findings.
Please do. Independently of that, there is another thing you can do.
Running without the init.el seems to stop the leakage. It's possible
that it is a problem (from what I've learned so far) from the XAE that gets
loaded via init.el XAE == Xml Authoring Environment
xae-1.0beta8
http://xae.sunsite.dk/xae-beta.tar.gz
Think of it this way: to the best of our knowledge, an idle timer
hook
is leaking memory. It might be either the problem with the hook or
with the timer mechanism. To narrow down the problem, you could:
1. Run (while t (cperl-get-help-defer)) and monitor the XEmacs process
for signs of leakage. If you don't detect leaking in several
minutes, there is probably no leak in that area.
Chewed on the cpu well enough but I observed no memory leak.
2. Run (run-with-idle-timer .1 t (lambda () nil)) and leave XEmacs for
the night. See if you get the leaks.
This is running but it looks inocuous so far.
Do these with the configuration that normally leaks, i.e. *not* with
`xemacs -q'. If you detect the leak in one (or both!) of these, we'll
narrow down the search for the culprit. If you don't, it might mean
that the problem lies either in interaction between the two or
somewhere else altogether.
I cannot detect a leak in 21.4.13 with either of the above methods.