X resource leak?

X resource leak?

[Óscar Fuentes]

On a emacs session that is running for 2 days with light usage, xrestop
shows this:

res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
2c00000    99   43    1 11251 11297     2445K    269K   2714K  5460 Emacs: *svn-st

For a previous session, after 20 days, the numbers were even higher
(replace 11000 above with ~ 30000 pixmaps and misc objects).

Emacs is by far the most X resource hungry application, with a crowded
web browser as a distant second, using 1453 pixmaps and 896 misc
objects.

A fresh emacs session starts with 45 pixmaps and 69 misc objects.

I'm not an experienced Emacs user on X-based graphical systems, so I
ask: are this numbers normal?

This is on Ubuntu 8.10.

In GNU Emacs 23.0.60.3 (x86_64-unknown-linux-gnu, GTK+ Version 2.14.4)
 of 2009-01-13 on qcore
Windowing system distributor `The X.Org Foundation', version 11.0.10502000

-- 
Oscar

Re: X resource leak?

[Chong Yidong]

> On a emacs session that is running for 2 days with light usage, xrestop
> shows this:
>
> res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
> 2c00000    99   43    1 11251 11297     2445K    269K   2714K  5460 Emacs: *svn-st
>
> For a previous session, after 20 days, the numbers were even higher
> (replace 11000 above with ~ 30000 pixmaps and misc objects).

I just fixed a small X resource leak in CVS, but I'm not sure that's
related to the numbers you're getting.  I have not able to induce a leak
of that magnitude.  For instance, even if I create lots of new frames,
closing those extra frames always brings the number of pixmaps allocated
back to its original value.

Could you do some experimentation to see what behavior is causing the
allocation of so many pixmaps?

Re: X resource leak?

[Óscar Fuentes]

Chong Yidong <cyd@stupidchicken.com> writes:

>> On a emacs session that is running for 2 days with light usage, xrestop
>> shows this:
>>
>> res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
>> 2c00000    99   43    1 11251 11297     2445K    269K   2714K  5460 Emacs: *svn-st
>>
>> For a previous session, after 20 days, the numbers were even higher
>> (replace 11000 above with ~ 30000 pixmaps and misc objects).
>
> I just fixed a small X resource leak in CVS, but I'm not sure that's
> related to the numbers you're getting.  I have not able to induce a leak
> of that magnitude.  For instance, even if I create lots of new frames,
> closing those extra frames always brings the number of pixmaps allocated
> back to its original value.
>
> Could you do some experimentation to see what behavior is causing the
> allocation of so many pixmaps?

I place an emacs -Q session and a konsole with xrestop side to
side. Just opening a file, scrolling through, etc, makes the number of
pixmaps and misc objects to grow. Killing the buffer does not reduce the
number of X resources used by emacs. Something as simple as C-x C-f C-g
increases the number of pixmaps by 4 (2 for C-x C-f and two more when I
abort with C-g). Is as if the allocated X resources never were freed.

Could you provide some hint about how to investigate this issue? I'm a
complete X-Windows ignorant, but know the basics about gdb (and I
willing to learn).

-- 
Oscar

Re: X resource leak?

[Chong Yidong]

Óscar Fuentes <ofv@wanadoo.es> writes:

> I place an emacs -Q session and a konsole with xrestop side to
> side. Just opening a file, scrolling through, etc, makes the number of
> pixmaps and misc objects to grow. Killing the buffer does not reduce the
> number of X resources used by emacs. Something as simple as C-x C-f C-g
> increases the number of pixmaps by 4 (2 for C-x C-f and two more when I
> abort with C-g). Is as if the allocated X resources never were freed.

I can not reproduce this.  Could you provide a *precise* recipe?

Re: X resource leak?

[Stephen J. Turnbull]

Chong Yidong writes:
 > Óscar Fuentes <ofv@wanadoo.es> writes:
 > 
 > > I place an emacs -Q session and a konsole with xrestop side to
 > > side. Just opening a file, scrolling through, etc, makes the number of
 > > pixmaps and misc objects to grow. Killing the buffer does not reduce the
 > > number of X resources used by emacs. Something as simple as C-x C-f C-g
 > > increases the number of pixmaps by 4 (2 for C-x C-f and two more when I
 > > abort with C-g). Is as if the allocated X resources never were freed.
 > 
 > I can not reproduce this.  Could you provide a *precise* recipe?

This sounds like the X server may not have the X Render extension
enabled, so Xft is using pixmaps to simulate X Render.  I have nothing
more to say about it, this is just hearsay from something I read
somewhere in passing (that for a couple of year Xft has had the
capability to use standard X calls to simulate X Render calls).
Anyway, it's easy to check for the X Render extension in the server
with xpdyinfo | grep -i render and in emacs with ldd | grep -i render.
If it's present as an extension in the server and linked in emacs,
probably that's not it.

Re: X resource leak?

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Chong Yidong writes:
>  > Óscar Fuentes <ofv@wanadoo.es> writes:
>  > 
>  > > I place an emacs -Q session and a konsole with xrestop side to
>  > > side. Just opening a file, scrolling through, etc, makes the number of
>  > > pixmaps and misc objects to grow. Killing the buffer does not reduce the
>  > > number of X resources used by emacs. Something as simple as C-x C-f C-g
>  > > increases the number of pixmaps by 4 (2 for C-x C-f and two more when I
>  > > abort with C-g). Is as if the allocated X resources never were freed.
>  > 
>  > I can not reproduce this.  Could you provide a *precise* recipe?

That's the precise recipe. I repeat:

emacs -Q

C-x C-f C-g

and the pixmap count increases by 4. C-x C-f C-g again, and it keeps
increasing.

I'm not expecting from you to reproduce the problem: it is so glaring
that if it were common it would already noticed. I'm looking for some
guidance on how to diagnose it on my machine.

> This sounds like the X server may not have the X Render extension
> enabled, so Xft is using pixmaps to simulate X Render.  I have nothing
> more to say about it, this is just hearsay from something I read
> somewhere in passing (that for a couple of year Xft has had the
> capability to use standard X calls to simulate X Render calls).
> Anyway, it's easy to check for the X Render extension in the server
> with xpdyinfo | grep -i render and in emacs with ldd | grep -i render.
> If it's present as an extension in the server and linked in emacs,
> probably that's not it.

/home/oscar $ ldd /usr/local/bin/emacs | grep -i render
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f8a5f9ba000)
	libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0x00007f8a5eb37000)
	libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007f8a5e92e000)

I have no xpdyinfo. Hope the above is enough to decide if the
exentension is working or not.

-- 
Oscar

Re: X resource leak?

[Werner LEMBERG]

> I have no xpdyinfo.

A typo.  It's called `xdpyinfo',


    Werner

Re: X resource leak?

[Óscar Fuentes]

Werner LEMBERG <wl@gnu.org> writes:

>> I have no xpdyinfo.
>
> A typo.  It's called `xdpyinfo',

Thanks!

oscar@qcore:~/$ xdpyinfo | grep -i render
    RENDER

-- 
Oscar

Re: X resource leak?

[Jan D.]

Can you tell us if you run KDE with gtk-engine? Is the toolbar enabled  
and if so does disabling it make any difference? Ditto for the  
scrollbar and menuar.

      Jan D.

19 jan 2009 kl. 04.10 skrev Chong Yidong <cyd@stupidchicken.com>:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> I place an emacs -Q session and a konsole with xrestop side to
>> side. Just opening a file, scrolling through, etc, makes the number  
>> of
>> pixmaps and misc objects to grow. Killing the buffer does not  
>> reduce the
>> number of X resources used by emacs. Something as simple as C-x C-f  
>> C-g
>> increases the number of pixmaps by 4 (2 for C-x C-f and two more  
>> when I
>> abort with C-g). Is as if the allocated X resources never were freed.
>
> I can not reproduce this.  Could you provide a *precise* recipe?
>

Re: X resource leak?

[Óscar Fuentes]

"Jan D." <jan.h.d@swipnet.se> writes:

> Can you tell us if you run KDE with gtk-engine?

I use KDE 4.1.3 (on Kubuntu x86_64) and Emacs is configured for using
the gtk widgets. It has

#define USE_GTK 1 

and

#define USE_TOOLKIT_SCROLL_BARS 1

> Is the toolbar enabled and if so does disabling it make any
> difference? Ditto for the scrollbar and menuar.

Bingo! After disabling the scroll bar with M-x scroll-bar-mode emacs
stops allocating X resources.

Switching on/off the menu bar and the tool bar shows no change on
the X resource allocation problem, so it is the scroll bar the only
culprit.

-- 
Oscar

Re: X resource leak?

[Jan Djärv]

Óscar Fuentes skrev:
> "Jan D." <jan.h.d@swipnet.se> writes:
> 
>> Can you tell us if you run KDE with gtk-engine?
> 
> I use KDE 4.1.3 (on Kubuntu x86_64) and Emacs is configured for using
> the gtk widgets. It has
> 
> #define USE_GTK 1 
> 
> and
> 
> #define USE_TOOLKIT_SCROLL_BARS 1
> 
>> Is the toolbar enabled and if so does disabling it make any
>> difference? Ditto for the scrollbar and menuar.
> 
> Bingo! After disabling the scroll bar with M-x scroll-bar-mode emacs
> stops allocating X resources.
> 
> Switching on/off the menu bar and the tool bar shows no change on
> the X resource allocation problem, so it is the scroll bar the only
> culprit.

What is the name of the theme you are using?

	Jan D.

Re: X resource leak?

[Óscar Fuentes]

Jan Djärv <jan.h.d@swipnet.se> writes:

>>> Can you tell us if you run KDE with gtk-engine?
>>
>> I use KDE 4.1.3 (on Kubuntu x86_64) and Emacs is configured for using
>> the gtk widgets. It has
>>
>> #define USE_GTK 1 
>>
>> and
>>
>> #define USE_TOOLKIT_SCROLL_BARS 1
>>
>>> Is the toolbar enabled and if so does disabling it make any
>>> difference? Ditto for the scrollbar and menuar.
>>
>> Bingo! After disabling the scroll bar with M-x scroll-bar-mode emacs
>> stops allocating X resources.
>>
>> Switching on/off the menu bar and the tool bar shows no change on
>> the X resource allocation problem, so it is the scroll bar the only
>> culprit.
>
> What is the name of the theme you are using?

I guess you mean the KDE theme. It's the default one (Oxygen) with
desktop effects off, with Cleanlooks widget style.

On System Settings -> Appearence there is a "GTK Styles and Fonts"
group. There, it is selected "Use my KDE style in GTK
applications". After selecting "Use another style:" and in the nearby
option list "Raleigh", the problem goes away (for new emacs sessions,
not for the existing ones). If I choose Qt4 instead of Raleigh, the
problem persists.

Having a workaround for this is great, as Emacs segfaults when the X
resources grow too high, which is after several days of use for me.

OTOH, if I can do something to further diagnose the problem, I'll be
glad to help.

Thanks Jan.

-- 
Oscar