X wizard needed

X wizard needed

[Richard Stallman]

[I sent this message a few weeks ago but did not get a response.
I hope we have someone who can help.]


Is there someone who knows how to trace X commands
to see what Emacs is sending that causes this memory leak?
Please send me mail if you can do it.


Date: Thu, 9 Jan 2003 15:02:47 +0000
From: Alan Morgan <arm@camcon.co.uk>
To: bug-gnu-emacs@gnu.org
Subject: Sun X server memory leak when running emacs 21.2
Sender: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.2 (sparc-sun-solaris2.6, OSF/Motif Version 1.2.6)
 of 2002-08-08 on athene
configured using `configure  --with-x-toolkit=motif --prefix=/usr/local/src/edcad/gnu'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

On Sun Solaris 2.6, when running emacs 21.2 with the menu bar enabled, the Sun
X server's memory usage increases with time, eventually making the machine
unreasonably slow.  This does not occur in emacs 20, nor in 21.2 if the menu
bar is disabled.

To see the behaviour, start an X login session, monitor the virtual memory
size of the Xsun process, and start a vanilla emacs with emacs -q. When emacs
processes commands, the Xsun memory usage is seen to rise, usually in chunks
of around 4-32k at a time. Opening files (with C-x C-f) and killing buffers
(C-x C-k), with no other activity, seems to show the behaviour. If emacs is
left undisturbed (no input) then the memory usage does not rise but stays
constant, however doing C-x C-f then causes a rise again, even C-x C-f C-g,
i.e. an aborted find file has the same effect.

I am aware that this could be a bug in Xsun, not in emacs, but I'm sorry I
don't know enough about the internals of X to know whether it is possible for
an application to legitimately cause the Xsun process to expand, or if this
has to imply a bug in the X implementation. I'd be interested to know which is
at fault.

Best Regards,

Alan

- 
-- 
Dr Alan Morgan             |                                 
Cambridge Consultants Ltd. |  Tel:  +44 (0)1223 420024 (switchboard)  
Science Park               |        +44 (0)1223 392682 (direct)
Milton Road                |        +44 (0)7785 714790 (mobile)
Cambridge                  |  Fax:  +44 (0)1223 423373   
CB4 0DW                    |  Email: arm@camcon.co.uk   
England                    |                                 



_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: X wizard needed

[Jan D.]

måndagen den 20 januari 2003 kl 01.50 skrev Richard Stallman:

> [I sent this message a few weeks ago but did not get a response.
> I hope we have someone who can help.]
>
>
> Is there someone who knows how to trace X commands
> to see what Emacs is sending that causes this memory leak?
> Please send me mail if you can do it.

I can take a look.  xmon can be used to trace X traffic.  It is possible
that some X window is not deleted when updating the menus.  But I'll see
if I can find anything.

	Jan D.

> Date: Thu, 9 Jan 2003 15:02:47 +0000
> From: Alan Morgan <arm@camcon.co.uk>
> To: bug-gnu-emacs@gnu.org
> Subject: Sun X server memory leak when running emacs 21.2
> Sender: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org
>
> This bug report will be sent to the Free Software Foundation,
> not to your local site managers!
> Please write in English, because the Emacs maintainers do not have
> translators to read other languages for them.
>
> Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
> and to the gnu.emacs.bug news group.
>
> In GNU Emacs 21.2.2 (sparc-sun-solaris2.6, OSF/Motif Version 1.2.6)
>  of 2002-08-08 on athene
> configured using `configure  --with-x-toolkit=motif 
> --prefix=/usr/local/src/edcad/gnu'
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: C
>   locale-coding-system: nil
>   default-enable-multibyte-characters: t
>
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> On Sun Solaris 2.6, when running emacs 21.2 with the menu bar enabled, the 
> Sun
> X server's memory usage increases with time, eventually making the machine
> unreasonably slow.  This does not occur in emacs 20, nor in 21.2 if the 
> menu
> bar is disabled.
>
> To see the behaviour, start an X login session, monitor the virtual memory
> size of the Xsun process, and start a vanilla emacs with emacs -q. When 
> emacs
> processes commands, the Xsun memory usage is seen to rise, usually in 
> chunks
> of around 4-32k at a time. Opening files (with C-x C-f) and killing buffers
> (C-x C-k), with no other activity, seems to show the behaviour. If emacs 
> is
> left undisturbed (no input) then the memory usage does not rise but stays
> constant, however doing C-x C-f then causes a rise again, even C-x C-f C-g,
> i.e. an aborted find file has the same effect.
>
> I am aware that this could be a bug in Xsun, not in emacs, but I'm sorry 
> I
> don't know enough about the internals of X to know whether it is possible 
> for
> an application to legitimately cause the Xsun process to expand, or if this
> has to imply a bug in the X implementation. I'd be interested to know 
> which is
> at fault.
>
> Best Regards,
>
> Alan
>
> -
> --
> Dr Alan Morgan             |
> Cambridge Consultants Ltd. |  Tel:  +44 (0)1223 420024 (switchboard)
> Science Park               |        +44 (0)1223 392682 (direct)
> Milton Road                |        +44 (0)7785 714790 (mobile)
> Cambridge                  |  Fax:  +44 (0)1223 423373
> CB4 0DW                    |  Email: arm@camcon.co.uk
> England                    |

Re: X wizard needed

[Eli Zaretskii]

> Date: Mon, 20 Jan 2003 20:14:47 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> 
> I can take a look.  xmon can be used to trace X traffic.

Perhaps you could add a few words to etc/DEBUG about using xmon for
such debugging.

TIA

Re: X wizard needed

[Jan D.]

Eli Zaretskii wrote:
>>Date: Mon, 20 Jan 2003 20:14:47 +0100
>>From: "Jan D." <jan.h.d@swipnet.se>
>>
>>I can take a look.  xmon can be used to trace X traffic.
> 
> 
> Perhaps you could add a few words to etc/DEBUG about using xmon for
> such debugging.

I'm not sure if I have anything general to say.  It is very dependent on what 
you are after and requires some X protocol (Xlib) knowledge.  But I can put in 
a line about how to get xmon for X tracing, if that is sufficient.

	Jan D.

Re: X wizard needed

[Eli Zaretskii]

> Date: Sun, 26 Jan 2003 14:38:56 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> 
> But I can put in 
> a line about how to get xmon for X tracing, if that is sufficient.

Perhaps that's all we need for now.

Re: X wizard needed

[Jan D.]

Eli Zaretskii wrote:
>>Date: Sun, 26 Jan 2003 14:38:56 +0100
>>From: "Jan D." <jan.h.d@swipnet.se>
>>
>>But I can put in 
>>a line about how to get xmon for X tracing, if that is sufficient.
> 
> 
> Perhaps that's all we need for now.

I added some text to etc/DEBUG.

	Jan D.

Re: X wizard needed

[Eli Zaretskii]

> Date: Mon, 27 Jan 2003 21:01:36 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> 
> I added some text to etc/DEBUG.

Thank you.

Re: X wizard needed

[Richard Stallman]

    I'm not sure if I have anything general to say.  It is very
    dependent on what you are after and requires some X protocol
    (Xlib) knowledge.  But I can put in a line about how to get xmon
    for X tracing, if that is sufficient.

Please write what you can.

Re: X wizard needed

[Richard Stallman]

    I can take a look.  xmon can be used to trace X traffic.  It is possible
    that some X window is not deleted when updating the menus.  But I'll see
    if I can find anything.

THank you.

Re: X wizard needed

[Jan D.]

[-- Attachment #1: Type: text/plain, Size: 3896 bytes --]

Jan D. wrote:
> 
> måndagen den 20 januari 2003 kl 01.50 skrev Richard Stallman:
> 
>> [I sent this message a few weeks ago but did not get a response.
>> I hope we have someone who can help.]
>>
>>
>> Is there someone who knows how to trace X commands
>> to see what Emacs is sending that causes this memory leak?
>> Please send me mail if you can do it.
> 
> 
> I can take a look.  xmon can be used to trace X traffic.  It is possible
> that some X window is not deleted when updating the menus.  But I'll see
> if I can find anything.

It turns out that no xmon was needed.  It is a general memory leak that is 
present on all systems.  It is both a leak in Emacs and a leak in the X server, 
since X windows aren't being deallocated.  I think this should go into RC.  Is 
it OK to put it in there (see attachement)?  I've tested it under XFree86, 
GNU/Linux and Solaris ix86.

	Jan D.


> 
>> Date: Thu, 9 Jan 2003 15:02:47 +0000
>> From: Alan Morgan <arm@camcon.co.uk>
>> To: bug-gnu-emacs@gnu.org
>> Subject: Sun X server memory leak when running emacs 21.2
>> Sender: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org
>>
>> This bug report will be sent to the Free Software Foundation,
>> not to your local site managers!
>> Please write in English, because the Emacs maintainers do not have
>> translators to read other languages for them.
>>
>> Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
>> and to the gnu.emacs.bug news group.
>>
>> In GNU Emacs 21.2.2 (sparc-sun-solaris2.6, OSF/Motif Version 1.2.6)
>>  of 2002-08-08 on athene
>> configured using `configure  --with-x-toolkit=motif 
>> --prefix=/usr/local/src/edcad/gnu'
>> Important settings:
>>   value of $LC_ALL: nil
>>   value of $LC_COLLATE: nil
>>   value of $LC_CTYPE: nil
>>   value of $LC_MESSAGES: nil
>>   value of $LC_MONETARY: nil
>>   value of $LC_NUMERIC: nil
>>   value of $LC_TIME: nil
>>   value of $LANG: C
>>   locale-coding-system: nil
>>   default-enable-multibyte-characters: t
>>
>> Please describe exactly what actions triggered the bug
>> and the precise symptoms of the bug:
>>
>> On Sun Solaris 2.6, when running emacs 21.2 with the menu bar enabled, 
>> the Sun
>> X server's memory usage increases with time, eventually making the 
>> machine
>> unreasonably slow.  This does not occur in emacs 20, nor in 21.2 if 
>> the menu
>> bar is disabled.
>>
>> To see the behaviour, start an X login session, monitor the virtual 
>> memory
>> size of the Xsun process, and start a vanilla emacs with emacs -q. 
>> When emacs
>> processes commands, the Xsun memory usage is seen to rise, usually in 
>> chunks
>> of around 4-32k at a time. Opening files (with C-x C-f) and killing 
>> buffers
>> (C-x C-k), with no other activity, seems to show the behaviour. If 
>> emacs is
>> left undisturbed (no input) then the memory usage does not rise but stays
>> constant, however doing C-x C-f then causes a rise again, even C-x C-f 
>> C-g,
>> i.e. an aborted find file has the same effect.
>>
>> I am aware that this could be a bug in Xsun, not in emacs, but I'm 
>> sorry I
>> don't know enough about the internals of X to know whether it is 
>> possible for
>> an application to legitimately cause the Xsun process to expand, or if 
>> this
>> has to imply a bug in the X implementation. I'd be interested to know 
>> which is
>> at fault.
>>
>> Best Regards,
>>
>> Alan
>>
>> -
>> -- 
>> Dr Alan Morgan             |
>> Cambridge Consultants Ltd. |  Tel:  +44 (0)1223 420024 (switchboard)
>> Science Park               |        +44 (0)1223 392682 (direct)
>> Milton Road                |        +44 (0)7785 714790 (mobile)
>> Cambridge                  |  Fax:  +44 (0)1223 423373
>> CB4 0DW                    |  Email: arm@camcon.co.uk
>> England                    |
> 
> 
> 


[-- Attachment #2: emacsRC.diff --]
[-- Type: text/plain, Size: 1043 bytes --]

Index: lwlib/lwlib-Xm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/lwlib/lwlib-Xm.c,v
retrieving revision 1.43
diff -c -r1.43 lwlib-Xm.c
*** lwlib/lwlib-Xm.c	22 Mar 2001 19:11:33 -0000	1.43
--- lwlib/lwlib-Xm.c	26 Jan 2003 13:28:55 -0000
***************
*** 265,271 ****
  	  XtSetArg (al[0], XmNsubMenuId, &submenu); 
    	  XtGetValues (children[i], al, 1);
  	  if (submenu)
! 	    XtDestroyWidget (submenu);
  	  XtDestroyWidget (children[i]);
  	}
  
--- 265,274 ----
  	  XtSetArg (al[0], XmNsubMenuId, &submenu); 
    	  XtGetValues (children[i], al, 1);
  	  if (submenu)
!             {
!               destroy_all_children (submenu, 0);
!               XtDestroyWidget (submenu);
!             }
  	  XtDestroyWidget (children[i]);
  	}
  
***************
*** 731,736 ****
--- 734,742 ----
  			     (XtPointer)instance);
  	      XtManageChild (button);
  	    }
+ 
+           if (widget_list)
+             XtFree ((char*) widget_list);
  	}
      }
    else if (!contents)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: X wizard needed

[Richard Stallman]

    It turns out that no xmon was needed.  It is a general memory leak
    that i s present on all systems.  It is both a leak in Emacs and a
    leak in the X s erver, since X windows aren't being deallocated.
    I think this should go into RC .

I agree--would you please install it?
Thank you very much.

Re: X wizard needed

[Jan D.]

Richard Stallman wrote:
>     It turns out that no xmon was needed.  It is a general memory leak
>     that i s present on all systems.  It is both a leak in Emacs and a
>     leak in the X s erver, since X windows aren't being deallocated.
>     I think this should go into RC .
> 
> I agree--would you please install it?
> Thank you very much.

Done.

	Jan D.

X wizard needed

[Richard Stallman]

Is there someone who knows how to trace X commands
to see what Emacs is sending that causes this memory leak?
Please send me mail if you can do it.


Date: Thu, 9 Jan 2003 15:02:47 +0000
From: Alan Morgan <arm@camcon.co.uk>
To: bug-gnu-emacs@gnu.org
Subject: Sun X server memory leak when running emacs 21.2
Sender: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.2 (sparc-sun-solaris2.6, OSF/Motif Version 1.2.6)
 of 2002-08-08 on athene
configured using `configure  --with-x-toolkit=motif --prefix=/usr/local/src/edcad/gnu'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

On Sun Solaris 2.6, when running emacs 21.2 with the menu bar enabled, the Sun
X server's memory usage increases with time, eventually making the machine
unreasonably slow.  This does not occur in emacs 20, nor in 21.2 if the menu
bar is disabled.

To see the behaviour, start an X login session, monitor the virtual memory
size of the Xsun process, and start a vanilla emacs with emacs -q. When emacs
processes commands, the Xsun memory usage is seen to rise, usually in chunks
of around 4-32k at a time. Opening files (with C-x C-f) and killing buffers
(C-x C-k), with no other activity, seems to show the behaviour. If emacs is
left undisturbed (no input) then the memory usage does not rise but stays
constant, however doing C-x C-f then causes a rise again, even C-x C-f C-g,
i.e. an aborted find file has the same effect.

I am aware that this could be a bug in Xsun, not in emacs, but I'm sorry I
don't know enough about the internals of X to know whether it is possible for
an application to legitimately cause the Xsun process to expand, or if this
has to imply a bug in the X implementation. I'd be interested to know which is
at fault.

Best Regards,

Alan

- 
-- 
Dr Alan Morgan             |                                 
Cambridge Consultants Ltd. |  Tel:  +44 (0)1223 420024 (switchboard)  
Science Park               |        +44 (0)1223 392682 (direct)
Milton Road                |        +44 (0)7785 714790 (mobile)
Cambridge                  |  Fax:  +44 (0)1223 423373   
CB4 0DW                    |  Email: arm@camcon.co.uk   
England                    |                                 



_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs