Re: GDI object leak with remote emacs
Takuma, I can't see what I'm doing different. The emacs I'm using is 20.7.1 on netbsd. I run X in -multiwindow mode. Could that have something to do with it? j Takuma Murakami writes: I cannot reproduce this in the following environments. - Cygwin DLL 1.5.5 and 1.5.7 - Cygwin/X release-44 - GNU Emacs 21.3 on FreeBSD 4.8 and 21.3 on MacOS X 10.3 - SFU not installed - invoked by 'ssh -CXf hostname emacs' In my task manager's process list XWin.exe allocates 2 GDI objects for a frame and the number of open files does not affect it. Closing a frame correctly reduces 2 GDI objects. Takuma Murakami
Re: GDI object leak with remote emacs
Jeremy, I can't see what I'm doing different. The emacs I'm using is 20.7.1 on netbsd. I run X in -multiwindow mode. Could that have something to do with it? I also tested with 20.7.1 on FreeBSD 4.8 and get no leak. My options for Cygwin/X is -multiwindow and -clipboard invoked from a slightly modified version of the startxwin.bat. Takuma Murakami
Re: GDI object leak with remote emacs
Jeremy, I don't know if this is related to the problems that people are experiencing with local copies of emacs but I'm seeing a GDI object leak with remote invocations of emacs that are routed back to my X server. Basically, I run cygwin/XFree86 on my local workstation, and I start an emacs on a Unix server that is displayed on my X server here. When using emacs, everytime I open a file, I can see that the XWin.exe processes gains a few GDI objects, but killing that buffer in emacs doesn't free them. Exiting emacs doesn't free them either. Once the leak grows enough (around 1500 GDI objects in XWin.exe) I start getting repaint problems and I have to kill X and restart it. I cannot reproduce this in the following environments. - Cygwin DLL 1.5.5 and 1.5.7 - Cygwin/X release-44 - GNU Emacs 21.3 on FreeBSD 4.8 and 21.3 on MacOS X 10.3 - SFU not installed - invoked by 'ssh -CXf hostname emacs' In my task manager's process list XWin.exe allocates 2 GDI objects for a frame and the number of open files does not affect it. Closing a frame correctly reduces 2 GDI objects. Takuma Murakami
GDI object leak with remote emacs
I don't know if this is related to the problems that people are experiencing with local copies of emacs but I'm seeing a GDI object leak with remote invocations of emacs that are routed back to my X server. Basically, I run cygwin/XFree86 on my local workstation, and I start an emacs on a Unix server that is displayed on my X server here. When using emacs, everytime I open a file, I can see that the XWin.exe processes gains a few GDI objects, but killing that buffer in emacs doesn't free them. Exiting emacs doesn't free them either. Once the leak grows enough (around 1500 GDI objects in XWin.exe) I start getting repaint problems and I have to kill X and restart it. This only started occuring when I updated my cygwin package last week. Below is my cygcheck output. Thanks, j Cygwin Win95/NT Configuration Diagnostics Current System Time: Wed Feb 11 17:24:47 2004 Windows 2000 Server Ver 5.0 Build 2195 Service Pack 4 Path: d:\cygwin\usr\local\bin d:\cygwin\bin d:\cygwin\bin d:\cygwin\usr\local\bin d:\cygwin\bin d:\cygwin\bin . d:\cygwin\bin d:\cygwin\usr\X11R6\bin d:\oracle\ora92\bin d:\Program Files\Oracle\jre\1.3.1\bin d:\Program Files\Oracle\jre\1.1.8\bin c:\WINNT\system32 c:\WINNT c:\WINNT\System32\Wbem d:\SFU\common\ c:\Program Files\Symantec\pcAnywhere\ Output from d:\cygwin\bin\id.exe (nontsec) UID: 1003(jetset) GID: 513(None) 513(None) Output from d:\cygwin\bin\id.exe (ntsec) UID: 1003(jetset) GID: 513(None) 513(None)544(Administrators) 547(Power Users) 545(Users) SysDir: C:\WINNT\system32 WinDir: C:\WINNT HOME = `d:\cygwin\home\jetset' MAKE_MODE = `unix' PWD = `/home/jetset' USER = `jetset' !EXITCODE = `' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\jetset\Application Data' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `BUTTERBALL' COMSPEC = `C:\WINNT\system32\cmd.exe' CYGWIN_ROOT = `\cygwin' DISPLAY = `127.0.0.1:0.0' GROUP = `None' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\jetset' HOST = `butterball' HOSTTYPE = `i386' LOGNAME = `jetset' LOGONSERVER = `\\BUTTERBALL' MACHTYPE = `i386' MANPATH = `:/usr/X11R6/man:/usr/ssl/man' NUMBER_OF_PROCESSORS = `1' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' OSTYPE = `posix' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 6 Stepping 0, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0600' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' SESSIONNAME = `Console' SFUDIR = `D:\SFU\' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TERM = `xterm' TZ = `EST5EDT4,M4.1.0/2,M10.5.0/2' USERDOMAIN = `BUTTERBALL' USERNAME = `jetset' USERPROFILE = `C:\Documents and Settings\jetset' VENDOR = `intel' WINDIR = `C:\WINNT' WINDOWID = `4194318' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `d:/cygwin' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `d:/cygwin/bin' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `d:/cygwin/lib' flags = 0x0002 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu\Programs\Cygnus Solutions (default) = (unsupported type) HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts (default) = `d:\cygwin\usr\X11R6\lib\X11\fonts' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd NTFS2437Mb 96% CP CS UN PA FC d: hd NTFS3075Mb 39% CP CS UN PA FC e: cd N/AN/A h: net NTFS 12110Mb 95% CP CSPAjetset d:/cygwin / userbinmode d:/cygwin/bin /usr/bin userbinmode d:/cygwin/lib /usr/lib userbinmode . /cygdrive userbinmode,cygdrive d:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode Found: d:\cygwin\bin\awk.exe Found: d:\cygwin\bin\bash.exe Found: d:\cygwin\bin\cat.exe Found: d:\cygwin\bin\cp.exe Found: d:\cygwin\bin\cpp.exe Found: d:\cygwin\bin\find.exe Found: d:\cygwin\bin\gcc.exe
Re: GDI object leak with remote emacs
On Wed, 11 Feb 2004, Jeremy Tan wrote: I don't know if this is related to the problems that people are experiencing with local copies of emacs but I'm seeing a GDI object leak with remote invocations of emacs that are routed back to my X server. Basically, I run cygwin/XFree86 on my local workstation, and I start an emacs on a Unix server that is displayed on my X server here. When using emacs, everytime I open a file, I can see that the XWin.exe processes gains a few GDI objects, but killing that buffer in emacs doesn't free them. Exiting emacs doesn't free them either. Once the leak grows enough (around 1500 GDI objects in XWin.exe) I start getting repaint problems and I have to kill X and restart it. This only started occuring when I updated my cygwin package last week. Below is my cygcheck output. Thanks, j FWIW, the same GDI object accumulation happens in Exceed. This is just a datapoint, though, and doesn't mean it shouldn't be fixed in XWin, if at all possible. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
