Subject: purify memory leaks

From: Brad Giaccio <[email-masked]>
Date: Tue, 1 Feb 2000 13:20:14 -0500

I finally talked purify into giving me the memory leaks when I exit
fvwm.  There appears to be main places one on parsing functions and the
other on processing styles.  I can obviouslly see the leak potential I'm
just not sure where to free.

Brad
--------------------------

MLK: 30656 bytes leaked in 580 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	expand         [functions.c:468]
	ExecuteFunction [functions.c:815]
	run_command_stream [read.c:81]
	run_command_file [read.c:154]
	ReadFile       [read.c:209]
	ExecuteFunction [functions.c:828]
	HandleModuleInput [module_interface.c:615]
	My_XNextEvent  [events.c:2294]
	HandleEvents   [events.c:244]
	main           [fvwm.c:708]

MLK: 2160 bytes leaked in 15 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	ProcessNewStyle [style.c:623]
	ExecuteFunction [functions.c:828]
	run_command_stream [read.c:81]
	run_command_file [read.c:154]
	ReadFile       [read.c:209]
	ExecuteFunction [functions.c:828]
	HandleModuleInput [module_interface.c:615]
	My_XNextEvent  [events.c:2294]
	HandleEvents   [events.c:244]
	main           [fvwm.c:708]

MLK: 1611 bytes leaked in 18 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	expand         [functions.c:468]
	ExecuteFunction [functions.c:815]
	AddToDecor     [builtins.c:1724]
	add_item_to_decor [builtins.c:1954]
	ExecuteFunction [functions.c:828]
	run_command_stream [read.c:81]
	run_command_file [read.c:154]
	ReadFile       [read.c:209]
	ExecuteFunction [functions.c:828]
	HandleModuleInput [module_interface.c:615]

MLK: 704 bytes leaked in 22 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	expand         [functions.c:468]
	ExecuteFunction [functions.c:815]
	run_command_stream [read.c:81]
	run_command_file [read.c:154]
	ReadFile       [read.c:209]
	ExecuteFunction [functions.c:828]
	SetRCDefaults  [fvwm.c:962]
	main           [fvwm.c:618]
	_start         [crt1.o]

MLK: 576 bytes leaked in 4 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	ProcessNewStyle [style.c:623]
	ExecuteFunction [functions.c:828]
	run_command_stream [read.c:81]
	run_command_file [read.c:154]
	ReadFile       [read.c:209]
	ExecuteFunction [functions.c:828]
	SetRCDefaults  [fvwm.c:962]
	main           [fvwm.c:618]
	_start         [crt1.o]

MLK: 156 bytes leaked in 3 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	expand         [functions.c:468]
	ExecuteFunction [functions.c:815]
	execute_complex_function [functions.c:1300]
	ComplexFunction [functions.c:1216]
	ExecuteFunction [functions.c:828]
	StartupStuff   [fvwm.c:769]
	My_XNextEvent  [events.c:2267]
	HandleEvents   [events.c:244]
	main           [fvwm.c:708]
	_start         [crt1.o]

MLK: 144 bytes leaked at 0x152668
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	ProcessNewStyle [style.c:623]
	ExecuteFunction [functions.c:828]
	SetRCDefaults  [fvwm.c:962]
	main           [fvwm.c:618]
	_start         [crt1.o]

MLK: 118 bytes leaked in 4 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	expand         [functions.c:468]
	ExecuteFunction [functions.c:815]
	execute_complex_function [functions.c:1300]
	ExecuteFunction [functions.c:834]
	ExecuteFunctionSaveTmpWin [functions.c:872]
	do_menu        [menus.c:812]
	do_windowList  [windowlist.c:512]
	ExecuteFunction [functions.c:828]
	HandleKeyPress [events.c:504]
	DispatchEvent  [events.c:210]

MLK: 63 bytes leaked at 0x1c9d88
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	expand         [functions.c:468]
	ExecuteFunction [functions.c:815]
	ExecuteFunctionSaveTmpWin [functions.c:872]
	do_menu        [menus.c:812]
	menu_func      [menus.c:5021]
	popup_func     [menus.c:5031]
	ExecuteFunction [functions.c:828]
	HandleKeyPress [events.c:504]
	DispatchEvent  [events.c:210]
	HandleEvents   [events.c:246]

MLK: 46 bytes leaked in 4 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	expand         [functions.c:468]
	ExecuteFunction [functions.c:815]
	WindowIdFunc   [conditional.c:740]
	ExecuteFunction [functions.c:828]
	execute_complex_function [functions.c:1300]
	ExecuteFunction [functions.c:834]
	ExecuteFunctionSaveTmpWin [functions.c:872]
	do_menu        [menus.c:812]
	do_windowList  [windowlist.c:512]
	ExecuteFunction [functions.c:828]

MLK: 34 bytes leaked at 0x1c1eb8
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	expand         [functions.c:468]
	ExecuteFunction [functions.c:815]
	run_command_stream [read.c:81]
	run_command_file [read.c:154]
	ReadFile       [read.c:209]
	ExecuteFunction [functions.c:828]
	run_command_stream [read.c:81]
	run_command_file [read.c:154]
	ReadFile       [read.c:209]
	ExecuteFunction [functions.c:828]

MLK: 24 bytes leaked at 0x157360
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	expand         [functions.c:468]
	ExecuteFunction [functions.c:815]
	ExecuteFunctionSaveTmpWin [functions.c:872]
	do_menu        [menus.c:812]
	do_windowList  [windowlist.c:512]
	ExecuteFunction [functions.c:828]
	HandleKeyPress [events.c:504]
	DispatchEvent  [events.c:210]
	HandleEvents   [events.c:246]
	main           [fvwm.c:708]

MLK: 6 bytes leaked at 0x1e7d30
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:42]
	expand         [functions.c:468]
	ExecuteFunction [functions.c:815]
	ExecuteFunctionSaveTmpWin [functions.c:872]
	do_menu        [menus.c:812]
	menu_func      [menus.c:5021]
	popup_func     [menus.c:5031]
	ExecuteFunction [functions.c:828]
	HandleButtonPress [events.c:1575]
	DispatchEvent  [events.c:210]
	HandleEvents   [events.c:246]

--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 2 Feb 2000 10:10:58 +0100

> just not sure where to free.

I think I've fixed both.  Please run Purify again and see if
that's right.

> 	HandleEvents   [events.c:244]

merge_style_list() deleted only the contents of the style, not the
style itself.

> 	HandleEvents   [events.c:244]

Expanded commands in nested functions were not freed again
due to a stupid bug in an if-clause.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 2 Feb 2000 09:42:01 -0500

> I think I've fixed both.  Please run Purify again and see if

Purify now leaks no memory (atleast with my config), could catch.
Despite the number of times I've been through expand that logic makes my
head hurt.

Now the only problem I have is 
FIU: file descriptor 7: "/etc/.name_service_door", O_RDONLY   * File info: ?r--r--r--  1 root     root             0 Jun 14  1999
   * This file descriptor was allocated from:
        __open64       [libc.so.1]
        _open64        [libc.so.1]
        _nsc_trydoorcall [libc.so.1]        _door_gethostbyname_r [gethostby_door.c]
        _get_hostserv_inetnetdir_byname [netdir_inet.c]
        gethostbyname_r [gethostbyname_r.c]
        _X11TransSocketINETConnect [libX11.so.6.0]
        _X11TransConnect [libX11.so.6.0]
        _X11TransConnectDisplay [libX11.so.6.0]
        XOpenDisplay   [libX11.so.6.0]
        main           [fvwm.c:357]
        _start         [crt1.o]

The obvious solution would be to call XCloseDisplay right before we
exit to ensure that resource are freed correctlly.  The only thing I'm
unsure of is that frees various images and graphics contexts, and I'm
not sure what that would do to any unswallowed apps that Buttons had
given a background too.  Given the case of exiting fvwm completelly then
starting it again without exiting the X server.

Thoughts?

Brad

---

From: Dan Espen <[email-masked]>
Date: Wed, 02 Feb 2000 09:51:03 -0500

Brad Giaccio <[email-masked]> writes:
> FIU: file descriptor 7: "/etc/.name_service_door", O_RDONLY   * File info: ?r
> 

The purify man page:

  .T1 "FIU" "File descriptor in use" "INFORMATIONAL" "fiu"
  At program exit, or when you call one of these API
  functions:
  .LP
  .nf
      \&\fB\&purify_new_fds_inuse();\&\fP\&
      \&\fB\&purify_all_fds_inuse();\&\fP\&
  .fi
  .LP
  a collection of FIU messages is generated.  Each
  message describes what is known about the origin
  of one open file descriptor.  If you see multiple
  file descriptors for the same file, or from the same
  call chain in the program, you should be concerned
  that you have a file descriptor leak, and your
  program may run out of file descriptors.

My reading of this implies that you should only consider this a problem
if you have multiple file descriptors for the same file.

It seems to me, just exiting and having the system close the file
is the least amount of code to get the desired affect.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
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-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Wed, 02 Feb 2000 14:52:42 +0000

> starting it again without exiting the X server.

I don't think it would make any difference. The only thing shared
between fvwm2 and the modules is the pixmaps for icons and mini-icons. 
They are going to get freed by the server when fvwm2 exits anyway so the
only difference will be exactly when it happens.

Cheers,
Tim.

PS we tried sharing graphics contexts, it didn't work well.

---

From: Brad Giaccio <[email-masked]>
Date: Wed, 2 Feb 2000 10:06:10 -0500

> if you have multiple file descriptors for the same file.

But when we do a fork and exec the file descriptor is left open, and I
wasn't sure if that could be a potential problem. and reading the man on
XCloseDisplay it just seems like the right thing to do.

The XCloseDisplay function closes the connection to the X
     server for the display specified in the Display structure
     and destroys all windows, resource IDs (Window, Font, Pix-
     map, Colormap, Cursor, and GContext), or other resources
     that the client has created on this display, unless the
     close-down mode of the resource has been changed (see
     XSetCloseDownMode).  Therefore, these windows, resource IDs,
     and other resources should never be referenced again or an
     error will be generated.  Before exiting, you should call
     XCloseDisplay explicitly so that any pending errors are
     reported as XCloseDisplay performs a final XSync operation.

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 2 Feb 2000 16:12:48 +0100

>         XOpenDisplay   [libX11.so.6.0]

What's a 'FIU'?

> exit to ensure that resource are freed correctlly.

Please don't do that.  The exit code is very touchy.  Changing the order
in which things are done is almost guaranteed to confuse some applications.

> The only thing I'm
> given a background too.

Nothing.  The X server stores a copy of the background pixmap.  You
can free it right after XSetBackgroundPixmap is called.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 2 Feb 2000 16:15:53 +0100

>      reported as XCloseDisplay performs a final XSync operation.

Ah, now I understand what you mean.  We already call XCloseDisplay
before exiting (except in a few error cases, e.g. when the 'fixed'
font can't be loaded).

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Wed, 02 Feb 2000 15:30:49 +0000

> XCloseDisplay it just seems like the right thing to do.
In fvwm/fvwm.c the X file descriptor is set to close on exec but it's
#ifdef'd with HAVE_X11_FD.  I guess that on most machines this is true
but vms/config.h has it #undef'd so modules on VMS machine will have an
extra file descriptor hanging around.
Maybe the safe thing to do is to add a #ifndef HAVE_X11_FD XCloseDpy()
between the fork and exec.

Cheers,
Tim.