Subject: Latest purify log

From: "Paul D. Smith" <[email-masked]>
Date: Tue, 10 Nov 1998 10:38:26 -0500 (EST)

Lookin' good!!!  The log is small enough that I don't feel the need to
post it gzipped :).

Hmm.  We still have a bothersome leak in the pixmap cache in
libs/Picture.c.  I took a medium-depth look at LoadPicture,
CachePicture, and a shorter look at DestroyPicture, and didn't notice
anything offhand.  It looks like someone must be free'ing the Picture
struct returned from CachePicture() without freeing the pixmaps.  Hmm.
Don't know if this is related but I see one probable leak; in
menus.c:AddToMenu() is this code:

      if (StrEquals(token2, "title"))
	{
	  tmp->next = menu->first->next;
	  free(menu->first);
	}

I don't think you can just free the MenuItem here.  Shouldn't there be a
FreeMenuItem() function or something that makes sure to free up any and
all pixmaps or other memory associated with the menu item?

And there are still a couple of other pixmap and stripcpy leaks.

-------------------------------------------------------------------------------

****  Purify instrumented /usr/local/pure/bin/fvwm2 (pid 23036 at Tue Nov 10 09:42:35 1998)
  * Purify 4.1-proto-S14 970822 SunOS 4.1, Copyright (C) 1992-1997 Pure Atria Corp. All rights reserved. 
  * For contact information type: "purify -help"
  * Command-line: /usr/local/pure/bin/fvwm2 -disply :1 
  * Options settings: -logfile=./pure.log -output-limit=5000000 \
    -auto-mount-prefix=/tmp_mnt -chain-length=25 -always-stop -purify \
    -purify-home=/app/pure/purify-4.1-proto-S14-sunos4 
  * Purify licensed to BAY NETWORKS
  * Purify checking enabled.

****  Purify instrumented /usr/local/pure/bin/fvwm2 (pid 23036)  ****
Process 23051 about to exec /bin/sh as "sh".

****  Purify instrumented /usr/local/pure/bin/fvwm2 (pid 23036)  ****
Current file descriptors in use: 5
FIU: file descriptor 0: <stdin>
FIU: file descriptor 1: <stdout>
FIU: file descriptor 2: <stderr>
FIU: file descriptor 26: <reserved for Purify internal use>
FIU: file descriptor 27: <reserved for Purify internal use>

****  Purify instrumented /usr/local/pure/bin/fvwm2 (pid 23036)  ****
Purify: Searching for all memory leaks...

Memory leaked: 622 bytes (0.65%); potentially leaked: 0 bytes (0%)

MLK: 332 bytes leaked in 15 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	XpmCreateImageFromXpmImage [libXpm.so.4.10]
	XpmCreatePixmapFromXpmImage [libXpm.so.4.10]
	LoadPicture    [Picture.c:99]
	CachePicture   [Picture.c:170]
	scanForPixmap  [menus.c:2139]
	AddToMenu      [menus.c:2297]
	add_another_item [builtins.c:525]
	ExecuteFunction [functions.c:247]
	ReadSubFunc    [read.c:160]
	ReadFile       [read.c:181]
	ExecuteFunction [functions.c:247]
	main           [fvwm.c:381]
	start          [crt0.o]
  * Block of 56 bytes at 0xdd040
  * Block of 32 bytes (3 times); last block at 0xdcc48
  * Block of 28 bytes (2 times); last block at 0xdc958
  * Block of 16 bytes (4 times); last block at 0xdcd10
  * Block of 12 bytes (5 times); last block at 0xe6cf0

MLK: 97 bytes leaked in 9 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:18]
	stripcpy       [Strings.c:104]
	AddWindow      [add_window.c:137]
	HandleMapRequestKeepRaised [events.c:704]
	HandleMapRequest [events.c:683]
	DispatchEvent  [events.c:155]
	HandleEvents   [events.c:176]
	main           [fvwm.c:465]
	start          [crt0.o]
  * Block of 16 bytes (2 times); last block at 0x1297a8
  * Block of 12 bytes (2 times); last block at 0xf3c90
  * Block of 10 bytes at 0xddad0
  * Block of 9 bytes at 0x120d98
  * Block of 8 bytes at 0xeff20
  * Block of 7 bytes (2 times); last block at 0x125750

MLK: 64 bytes leaked in 4 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	XpmCreateImageFromXpmImage [libXpm.so.4.10]
	XpmCreatePixmapFromXpmImage [libXpm.so.4.10]
	LoadPicture    [Picture.c:99]
	CachePicture   [Picture.c:170]
	ReadButtonFace [builtins.c:2286]
	ReadTitleButton [builtins.c:2523]
	ButtonStyle    [builtins.c:2915]
	ExecuteFunction [functions.c:247]
	AddToDecor     [builtins.c:2574]
	add_another_item [builtins.c:538]
	ExecuteFunction [functions.c:247]
	ReadSubFunc    [read.c:160]
	ReadFile       [read.c:181]
	ExecuteFunction [functions.c:247]
	main           [fvwm.c:381]
	start          [crt0.o]
  * Block of 20 bytes at 0xbafd8
  * Block of 16 bytes (2 times); last block at 0xbeef8
  * Block of 12 bytes at 0xb2a68

MLK: 64 bytes leaked in 2 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	XpmCreateImageFromXpmImage [libXpm.so.4.10]
	XpmCreatePixmapFromXpmImage [libXpm.so.4.10]
	GetXPMFile     [icons.c:707]
	CreateIconWindow [icons.c:76]
	Iconify        [icons.c:935]
	iconify_function [builtins.c:686]
	ExecuteFunction [functions.c:247]
	HandleButtonPress [events.c:1121]
	DispatchEvent  [events.c:155]
	HandleEvents   [events.c:176]
	main           [fvwm.c:465]
	start          [crt0.o]
  * Block of 32 bytes (2 times); last block at 0x122240

MLK: 48 bytes leaked in 2 blocks
  * This memory was allocated from:
	malloc         [rtlib.o]
	XpmCreateImageFromXpmImage [libXpm.so.4.10]
	XpmCreatePixmapFromXpmImage [libXpm.so.4.10]
	LoadPicture    [Picture.c:99]
	CachePicture   [Picture.c:170]
	AddWindow      [add_window.c:603]
	HandleMapRequestKeepRaised [events.c:704]
	HandleMapRequest [events.c:683]
	DispatchEvent  [events.c:155]
	HandleEvents   [events.c:176]
	main           [fvwm.c:465]
	start          [crt0.o]
  * Block of 28 bytes at 0xa4840
  * Block of 20 bytes at 0x128058

MLK: 17 bytes leaked at 0x1131c0
  * This memory was allocated from:
	malloc         [rtlib.o]
	safemalloc     [safemalloc.c:18]
	stripcpy       [Strings.c:104]
	NewMenuRoot    [menus.c:2379]
	do_windowList  [windows.c:172]
	ExecuteFunction [functions.c:247]
	HandleButtonPress [events.c:1121]
	DispatchEvent  [events.c:155]
	HandleEvents   [events.c:176]
	main           [fvwm.c:465]
	start          [crt0.o]

Purify Heap Analysis (combining suppressed and unsuppressed blocks)
                         Blocks      Bytes
              Leaked         34        634
  Potentially Leaked          0          0
              In-Use       2057      95052
  ----------------------------------------
     Total Allocated       2091      95686

****  Purify instrumented /usr/local/pure/bin/fvwm2 (pid 23036)  ****
  * Program exited with status code 0.
  * 0 access errors, 0 total occurrences.
  * 622 bytes leaked.
  * 0 bytes potentially leaked.
  * Basic memory usage (including Purify overhead):
      556764 code
       87728 data/bss
      671752 heap (peak use)
        4304 stack
  * Shared library memory usage (including Purify overhead):
       98304 libXpm_pure_p3_c0_108220257_413_U1V.so.4.10 (shared code)
        8192 libXpm_pure_p3_c0_108220257_413_U1V.so.4.10 (private data)
       49152 libSM_pure_p3_c0_108220257_413_U1V.so.6.0 (shared code)
        8192 libSM_pure_p3_c0_108220257_413_U1V.so.6.0 (private data)
       98304 libICE_pure_p3_c0_108220257_413_U1V.so.6.3 (shared code)
        8192 libICE_pure_p3_c0_108220257_413_U1V.so.6.3 (private data)
       73728 libXext_pure_p3_c0_108220257_413_U1V.so.4.40 (shared code)
        8192 libXext_pure_p3_c0_108220257_413_U1V.so.4.40 (private data)
     1114112 libX11_pure_p3_c0_108220257_413_U1V.so.4.30 (shared code)
       74040 libX11_pure_p3_c0_108220257_413_U1V.so.4.30 (private data)
      688128 libc_pure_p3_c0_108220257_413_U1V.so.1.9 (shared code)
       16384 libc_pure_p3_c0_108220257_413_U1V.so.1.9 (private data)
        8192 libdl.so.1.0 (shared code)
        8192 libdl.so.1.0 (private data)
        8192 libinternal_stubs.so.1.0 (shared code)
        8192 libinternal_stubs.so.1.0 (private data)

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: [email-masked]
Date: Tue, 10 Nov 1998 17:56:11 +0100

> Lookin' good!!!  The log is small enough that I don't feel the need to

Good. I was hoping for a smaller update of the log so I can
concentrate on the remaining problems. However we will
probably discover new leaks if we make a config-file that
uses more of the features.

> struct returned from CachePicture() without freeing the pixmaps.  Hmm.

Can't purify detect this somehow?

> all pixmaps or other memory associated with the menu item?

You're right. I'll try to do this.

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: [email-masked] (Paul D. Smith)
Date: 10 Nov 1998 13:18:03 -0500

%% [email-masked] writes:

  dv> Good. I was hoping for a smaller update of the log so I can
  dv> concentrate on the remaining problems. However we will probably
  dv> discover new leaks if we make a config-file that uses more of the
  dv> features.

I agree; mine is pretty basic.

  >> struct returned from CachePicture() without freeing the pixmaps.  Hmm.

  dv> Can't purify detect this somehow?

No, I don't think so.

It only looks for lost heap at the end of processing (or, alternatively,
you can ask it to look yourself by breaking the app with a debugger and
calling an internal purify function--if we had an idea of where the
problem was I could probably narrow it down that way.)

---

From: [email-masked]
Date: Thu, 12 Nov 1998 10:58:48 +0100

All leaks in the last log are fixed. Problably. I can't say
for sure since I do not really know where some of these came
from. I fixed leaks that could have caused any of them, but
maybe there's something else left.

Bye

Dominik