Re: Notification: incoming/719
On Fri, Jun 08, 2001 at 10:56:55AM -0400, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: I don't normally use icon titles so I might have missed them in previous tests. Also I'm not sure if leaks at termination are really leaks, if you are going to exit, theres no point in freeing things. It does look like there were 8 icon fonts allocated. Thats close to the number of windows I created. You can easily verify that with the patch you suggest (already committed). I see the growing size too, but to a smaller extent (with the patch, I did not try before). The sizes I saw were less than the 10-20K per process reported. I'd guess the memory lost by failing to free a font would vary depending on the X server. Sometimes some application seems to freak out and start to consume memory slowly, but I could not identify which yet. I suspect it's either FvwmButtons (unlikely) or one of the swallowed apps (xload or xosview). Well, perhaps one of these is simply recording a history in malloc'ed memory. I'm only looking at the memory used by fvwm2, thats all that was mentioned by Andrey. Could you set Purify to the cause and see if it helps identifying any leaks here? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/719
On Fri, Jun 22, 2001 at 08:16:33AM -0400, Dan Espen wrote: Dominik Vogt [EMAIL PROTECTED] writes: On Fri, Jun 08, 2001 at 10:56:55AM -0400, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: I don't normally use icon titles so I might have missed them in previous tests. Also I'm not sure if leaks at termination are really leaks, if you are going to exit, theres no point in freeing things. It does look like there were 8 icon fonts allocated. Thats close to the number of windows I created. You can easily verify that with the patch you suggest (already committed). I see the growing size too, but to a smaller extent (with the patch, I did not try before). The sizes I saw were less than the 10-20K per process reported. I'd guess the memory lost by failing to free a font would vary depending on the X server. Sometimes some application seems to freak out and start to consume memory slowly, but I could not identify which yet. I suspect it's either FvwmButtons (unlikely) or one of the swallowed apps (xload or xosview). Well, perhaps one of these is simply recording a history in malloc'ed memory. I'm only looking at the memory used by fvwm2, thats all that was mentioned by Andrey. Could you set Purify to the cause and see if it helps identifying any leaks here? I'm not sure what you are asking for. Would you like me to run FvwmButtons under Purify? No, I mean fvwm itself. If there is a memory leak, Purify might be able to detect it. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/719
Dominik Vogt fvwm-workers@fvwm.org writes: I don't normally use icon titles so I might have missed them in previous tests. Also I'm not sure if leaks at termination are really leaks, if you are going to exit, theres no point in freeing things. It does look like there were 8 icon fonts allocated. Thats close to the number of windows I created. You can easily verify that with the patch you suggest (already committed). I see the growing size too, but to a smaller extent (with the patch, I did not try before). The sizes I saw were less than the 10-20K per process reported. I'd guess the memory lost by failing to free a font would vary depending on the X server. Sometimes some application seems to freak out and start to consume memory slowly, but I could not identify which yet. I suspect it's either FvwmButtons (unlikely) or one of the swallowed apps (xload or xosview). Well, perhaps one of these is simply recording a history in malloc'ed memory. I'm only looking at the memory used by fvwm2, thats all that was mentioned by Andrey. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/719
9 2001 01:07, ?? : Ah, I remember we discovered several memory leaks in X11. One is in the XGetWMNormalHints() funtion which is called once for every new window. Maybe it's one of those. I want to note that last time I used XFree-4.1.0 -- Andrey Panov http://canopus.iacp.dvo.ru/~panov/ E-mail: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/719
On Wed, Jun 06, 2001 at 10:34:44PM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/719 Full_Name: Andrey Panov Version: 2.3.32 CVS_Date: OS: linux-2.4.5 X_Server: XFree-4.0.3 Submission from: (NULL) (62.76.7.3) I was running fvwm-2.3.32 for 8 days and it occupied about 10Mb of memory. This is line from top: 14091 panov 9 0 10432 1588 1280 S 0 0.0 2.5 12:32 fvwm2 For all this time I did not run any themes, pipes and so on. I use fixed fvwm2rc file (but create gnome and kde menus on start with PipeRead 'fvwm-menu-desktop ...'). After Restart (from its menu) fvwm occupies about 2 Mb. It looks like a memory leak in fvwm. My system is i386, linux-2.4.5, glibc-2.2.3, gcc-2.95.3, XFree-4.0.3. I configured fvwm with --enable-multibyte option. Note that the top output is hard to interpret and does not necessarily mean that fvwm itself is using this much memory. The plain fvwm code has been tested for memory leaks very thoroughly, so it's higly unlikely that we missed a leak this big. On the other hand the multibyte code is still experimental and has not undergone extensive tests. Please 1) provide your config file. 2) Send the output of fvwm2 -version. 3) Try to identify a any action that increases the size of fvwm2 reported by top. A general description of your day to day tasks (regarding fvwm) might help to check the problem too. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/719
7 Июнь 2001 20:40, Вы написали: Note that the top output is hard to interpret and does not necessarily mean that fvwm itself is using this much memory. The plain fvwm code has been tested for memory leaks very thoroughly, so it's higly unlikely that we missed a leak this big. On the other hand the multibyte code is still experimental and has not undergone extensive tests. Please 1) provide your config file. 2) Send the output of fvwm2 -version. 3) Try to identify a any action that increases the size of fvwm2 reported by top. A general description of your day to day tasks (regarding fvwm) might help to check the problem too. I use fvwm on my desctop with usual tasks: running konqueror, kmail, knode, xterm windows, nedit, licq, qps. I have been using fvwm with config file attached for years with small changes. I have used fvwm 2.3 series since 2.3.19. ~$ fvwm2 -version FVWM version 2.3.32 compiled on May 11 2001 at 13:18:41 with support for: ReadLine, XPM, GNOME WM hints, SM, Multibyte It seems that opening of new window increases fvwm's memory size by 10-20Kb and memory is not freed after closing of the window. -- Andrey Panov http://canopus.iacp.dvo.ru/~panov/ E-mail: [EMAIL PROTECTED] ## # # Now define the menus - defer bindings until later # # This is for the Start menu of the FvwmTaskBar AddToMenu StartMenu StartMenu Title + New shell%mini-sh1.xpm% Execcolor_xterm -ls -sb -fn 7x14 -fg white -bg black #+ xrus Exec xrus /usr/local/share/xruskb/jcuken-koi8.xmm -geometry 4x1+0+0 + Top%mini-run.xpm% Exec xterm -font 6x10 -geometry 100x53 -bg \#c0c0c0 -fg black -T Top -n Top -e top + xrus Exec xrus jcuken-koi8.xmm -geometry 4x1+0+0 + Manual pages %mini-book1.xpm% Execxman + Magnifying glass %mini-zoom.xpm%Exec xmag + Applications %mini-x2.xpm% Popup Applications + Games%mini-happy.xpm% Popup Games + Kde menu%mini.kde.xpm Popup kde-sys + Gnome menu%mini.gnome.xpm% Popup gnome-sys + Nop + Lock Screen %mini-lock.xpm%Execxlock + Refresh Screen %mini-ray.xpm% Refresh + Nop + Exit Fvwm2 %mini-stop.xpm%Popup Quit-Verify AddToMenu Shells Shells Title + Color Xterm (6x10 font)%mini-term.xpm% Exec color_xterm -ls -sb -fn 6x10 -fg white -bg black -title Color xterm + Color Xterm (6x13 font)%mini-term.xpm% Exec color_xterm -ls -sb -fn 6x13 -fg white -bg black -title Color xterm + Color Xterm (9x15 font)%mini-term.xpm% Exec color_xterm -ls -sb -fn 9x15 -fg white -bg black -title Color xterm + Nop + Xterm(7x14 font)%mini-term.xpm% Exec xterm -sb -sl 500 -j -ls -fn 7x14 + Color Rxvt (VT100)%mini-term.xpm% Exec rxvt -font 7x14 -ls + Color Xterm (7x14 font)%mini-term.xpm% Exec color_xterm -sb -sl 500 -j -ls -fn 7x14 -fb 7x14bold -title Color xterm + Color Xterm (8x13 font)%mini-term.xpm% Exec color_xterm -sb -sl 500 -j -ls -fn 8x13 -title Color xterm + Nop + Large Xterm (10x20 font)%mini-term.xpm%Exec xterm -sb -sl 500 -j -ls -fn 10x20 + Large Rxvt (10x20 font)%mini-term.xpm%Exec rxvt -font 10x20 -ls + Large Color Xterm(10x20 font)%mini-term.xpm% Exec color_xterm -sb -sl 500 -j -ls -fn 10x20 + Nop + kvt%kvt.xpm% Exec kvt AddToMenu Screensaver1 Screensaver (a-h) Title + Ant%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode ant + Ball%mini-bball.xpm%Exec xlock -nolock -nice 0 -mode ball + Bat%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode bat + Blank%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode blank + Blot%mini-bball.xpm%Exec xlock -nolock -nice 0 -mode blot + Bomb%mini-bball.xpm%Exec xlock -nolock -nice 0 -mode bomb + Bouboule%mini-bball.xpm%Exec xlock -nolock -nice 0 -mode bouboule + Bob%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode image + Bounce%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode bounce + Braid%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode braid + Bug%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode bug + Clock%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode clock + Daisy%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode daisy + Dclock%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode dclock + Demon%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode demon + Drift%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode drift + Eyes%mini-bball.xpm%Exec xlock -nolock -nice 0 -mode eyes + Flag%mini-bball.xpm%Exec xlock -nolock -nice 0 -mode flag + Flame%mini-bball.xpm% Exec xlock -nolock -nice 0 -mode flame +
Re: Notification: incoming/719
Andrey Panov [EMAIL PROTECTED] writes: Note that the top output is hard to interpret and does not necessarily mean that fvwm itself is using this much memory. The plain fvwm code has been tested for memory leaks very thoroughly, so it's higly unlikely that we missed a leak this big. On the other hand the multibyte code is still experimental and has not undergone extensive tests. Please 1) provide your config file. 2) Send the output of fvwm2 -version. 3) Try to identify a any action that increases the size of fvwm2 reported by top. A general description of your day to day tasks (regarding fvwm) might help to check the problem too. I use fvwm on my desctop with usual tasks: running konqueror, kmail, knode, xterm windows, nedit, licq, qps. I have been using fvwm with config file attached for years with small changes . I have used fvwm 2.3 series since 2.3.19. ~$ fvwm2 -version FVWM version 2.3.32 compiled on May 11 2001 at 13:18:41 with support for: ReadLine, XPM, GNOME WM hints, SM, Multibyte It seems that opening of new window increases fvwm's memory size by 10-20Kb and memory is not freed after closing of the window. Hmm. This is just to help collect data on this problem. I'm using fvwm 2.3.33 from about a week ago. I just created 11 rxvt's with no impact on fvwm's size (not even 1K) as reported by top. Have ReadLine support? yes Have RPlay support in FvwmEvent? no: Can't find required librplay Have Stroke support? no: Can't find required libstroke Have XPM support? yes Have GNOME Window Manager support? yes Have Session Management support? yes Have GTK support for FvwmGtk? yes Have GDK Imlib support in FvwmGtk? no: Failed on gdk-imlib, see config.log Have GNOME support in FvwmGtk? no: Can't find working gnome-config Have Multibyte support?no: This is the suggested default -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
