Subject: FVWM CVS: fvwm domivogt

From: CVS <[email-masked]>
Date: Sun, 6 Dec 1998 15:48:26 -0600 (CST)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	98/12/06 15:48:25

Modified files:
	.              : ChangeLog 
	fvwm           : builtins.c windows.c 
	modules        : ChangeLog 
	modules/FvwmPager: FvwmPager.1 x_pager.c 

Log message:
fixed memory leak in ReadButtonFace (?)
fixed memory leak in SetEnv
* fvwm/windows.c (do_windowList): DestroyMenu called as soon as
possible (might cause problems with WindowList as doubleclick action).
x_pager.c: removed unnecessary ifdef, fixed mouse-button-3 bug with multiple
desktops, changed mouse button 3 behaviour

--
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: Brad Giaccio <[email-masked]>
Date: Mon, 7 Dec 1998 15:00:14 -0500 (EST)

Dominik,
I noticed that with my setup 2 desks, 0 and 1.  If I use mouse 3 on the
second desk all my geometries get hosssed on the first desk.  Not that I
care much, since I never tried mouse 3 untiul this thread about the
negatived desks started.

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous

---

From: [email-masked] (Paul D. Smith)
Date: 08 Dec 1998 01:36:42 -0500

%% Regarding FVWM CVS: fvwm domivogt writes

  c> fixed memory leak in SetEnv

You need to undo this change.  You cannot free that memory that you pass
to putenv().  putenv() takes that memory and installs it _directly_ into
the environment, it doesn't make a copy.  See the man page:

     putenv() makes the value of the environment  variable  name  equal to
     value  by  altering  an  existing  variable or creating a new one. In
     either case, the string pointed to  by  string  becomes  part  of the
     environment,  so  altering  the  string  will  change the environment.

That's why I said in my original message that fixing this leak was hard
and, ultimately, will almost certainly cost more memory in code than the
typical user will waste using SetEnv.  The only way I can think of to do
it would be to store a list of pointers to previously putenv()'d things,
so you can free them later.  Some people try to play games with the
return value from getenv(), but I don't trust it myself.

-- 
-------------------------------------------------------------------------------
 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: Dominik Vogt <[email-masked]>
Date: Tue, 8 Dec 1998 11:05:10 +0100

> return value from getenv(), but I don't trust it myself.

You mean it just uses the whole assignment string 'foo=bar'?
Perhaps I shouldn't 'fix' leaks after 2 AM ;-) Hmm, I didn't
find it in the manpage or else I wouldn't have done it.

BTW, did you have a chance to look at that menus.c memory
leak problem? I'm really stumped on this. I scanned the code
up and down and the only conclusion I came to is that some
menu item seems to be overwritten or isn't deleted when the
menu is killed. I can't find a place in the code that might
cause 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: 08 Dec 1998 11:48:03 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv> You mean it just uses the whole assignment string 'foo=bar'?

Yep.  Pretty poor API design, but there you go.

  dv> BTW, did you have a chance to look at that menus.c memory
  dv> leak problem? I'm really stumped on this. I scanned the code
  dv> up and down and the only conclusion I came to is that some
  dv> menu item seems to be overwritten or isn't deleted when the
  dv> menu is killed. I can't find a place in the code that might
  dv> cause this.

Not yet.  I'm going to take a look through the Purify manual and see if
I can find some flags to give more info.

For example, for a while back when I worked on DG/UX I used Conor
Cahill's dbmalloc library, and that would print things like the number
of calls to malloc before the one that leaked, etc. so you could use
intelligent conditional breakpoints and see what was going on.

Maybe Purify has some way of getting more info, even if it makes the app
run dog-slow.

It seems like there must be a free of menus that's being done outside of
the DestroyMenu() or whatever function, and isn't cleaning up.  We need
to see if we can find that call.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 8 Dec 1998 18:51:17 +0100

On Tue, Dec 08, 1998 at 11:48:03AM -0500, Paul Smith wrote:
> ...

No, there's no such call. I've checked it again and again and
all the the places where menus are created have a valid counterpart
that takes care of deleting the menu. I see no possibility how
DestroyMenu could miss a particular menu item while deleting an no
other code deletes anything from a menu. One idea might be that this
has something to do with popping up menus before MakeMenus is called?
That's the case in the script. I think it might help if I could at least
see the data in the leaked memory. Can that be done?

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 9 Dec 1998 11:42:27 +0100

> care much, since I never tried mouse 3 untiul this thread about the

I worked on this but are not sure if I fixed it. Can you verify
that? (I still don't really know what you mean).

Bye

Dominik

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 17 Dec 1998 07:49:39 -0500 (EST)

> that? (I still don't really know what you mean).

This now seems to be fixed.