Subject: CVS olicha: * Fixed one tone of bugs (leak/core dump) in fvwm:

From: FVWM CVS <[email-masked]>
Date: Sun, 18 May 2003 13:12:15 -0500

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	olicha	03/05/18 13:12:15

Modified files:
	.              : ChangeLog 
	fvwm           : add_window.c borders.c builtins.c conditional.c 
	                 functions.c fvwm.c menustyle.c menustyle.h 
	                 windowlist.c 
	libs           : FGettext.c Flocale.c defaults.h 
	tests          : ChangeLog 
	tests/purify   : purify.fvwm2rc 

Log message:
* Fixed one tone of bugs (leak/core dump) in fvwm:
* Some purify.fvwm2rc update
* Fixed a memory leak (a FvwmWindow !) when a window is not destroyed
but scheduled for destroy. Not sure that this is the good fix.
* Fixed the default buttons memory leak and
* Removed inconsistent #if 0 code and comments about leak and MiniIcon
decor style
* Limited the depth of function to MAX_FUNCTION_DEPTH (=512). This fixes
cores dumps with "recursive" functions
* Fixed a core dump with a root transparent rotated title bar
* Fixed X errors 56 with RootTransparent titlebar and no E pixmap
* Fixed memory leak and chaining in LocalePath
* Fixed a parsing leak in PrintInfo
* Fixed a mask memory leaks in Circulate
* Fixed a core dump when a 0 font is given with an encoding hints
* Added a default FFT font
* Fixed a core dump when the default font change and a redraw (icon or
window) is proceeded before flush_window_updates is called
* Fixed gradients copy in CopyMenuStyle
* Fixed UMR's related to colorset in menus styles
* Fixed a fore stipple gc leak in menus style
* Fixed a sor_keyname memory leak in WindowList
* Added x,r,w,f,i file conditions to the On command

--
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: Olivier Chapuis <[email-masked]>
Date: Sun, 18 May 2003 20:27:12 +0200

> * Some purify.fvwm2rc update

Again Valgrind help as well as fvwm-themes and purify.fvwm2rc

> but scheduled for destroy. Not sure that this is the good fix.

When an FvwmWindow is destroyed and should be SCHEDULED_FOR_DESTROY,
with the old code, it seems that the associated FvwmWindow structure
is never freed. The reason is that the window is removed from the
list of the fvwm windows before the window is set SCHEDULED_FOR_DESTROY
and the struct is not freed.
What I do: Keep the window in the fvwm windows list until it is really
destroyed. This seems logic for me (regarding the existence of the 
SCHEDULED_FOR_DESTROY bit), but I am just afraid to add bugs to
complex functions. An other possibility is remove from list and
to add a list for the windows which are scheduled for destroy.
Any comments?

> * Removed inconsistent #if 0 code and comments about leak and MiniIcon

I _hope_ that I've fixed all the memory leaks in the decoration parsing
code. However, I am maybe a bit naive here as I've just added one line
and removed some comments and unused code.
Dominik any comments?

> cores dumps with "recursive" functions

[snip]

> * Added x,r,w,f,i file conditions to the On command

Ooops, a new feature that appear under my hands during this debugging
session (do not know really why ...).
If someone want I can remove it at once. If not I will document it
(usual file access tests X_OK, R_OK, ... but for x (X_OK) the file
is also searched in $PATH. i is R_OK access in the ImagePath.) 

Regards, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 19 May 2003 08:30:00 +0200

> to add a list for the windows which are scheduled for destroy.

Use a separate list.  Windows schedules for destruction *must not*
show up in the regular window list.

> and removed some comments and unused code.

Yeah, maybe you are a bit naive here ;-)  I have long given up all
hope to ever fix the decor code other than by removing it.  To say
more I need a hint where to look.

> > cores dumps with "recursive" functions

Good idea.

> > * Added x,r,w,f,i file conditions to the On command

What does it do?

In any case, it should have a separate command, not mix with other
non-related commands.

> is also searched in $PATH. i is R_OK access in the ImagePath.) 

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 19 May 2003 09:34:19 +0000

> > is also searched in $PATH. i is R_OK access in the ImagePath.) 

Actually I added the command On exactly for this purpose, to have a non
window related conditions. So this or similar syntax seems ok for me:

  On (Restart) Beep

  On (-x /usr/bin/gdialog) Exec gdialog --msgbox text 100 100
  Cond (NoMatch) On (-x /usr/bin/xmessage) Exec xmessage text

  On (!ReadableImagePath) On (-X xmessage) Exec xmessage "Bad ImagePath"

I think "On (!ReadableImagePath, -X xmessage)" syntax should work too.
BTW, this means I don't think "-i" is a good name, ReadableImagePath is.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 21 May 2003 01:37:21 +0000

> BTW, this means I don't think "-i" is a good name, ReadableImagePath is.

After actually reading the sources, I see it is more "ReadableImage".

So, I think I prefer these names instead:

  -x, -r, -f   - the same as the equal file flags in test/shell/perl
  -X, -I, -M   - search for the given executable/image/module in its PATH

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 21 May 2003 22:34:24 +0200

>   -X, -I, -M   - search for the given executable/image/module in its PATH

Dot no see why we need a "-". Moreover, if you want a -x (without
path search) give a full path to -X (with your terminolgy).

So I think that  x,r,w,f,i,m are ok.

Regards, Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 21 May 2003 23:39:48 +0000

> path search) give a full path to -X (with your terminolgy).

I didn't feel a need to mix things (-r does not searches in $PATH, so why
should -x), think about non-Unix operating systems with a non slash.
At least tcsh has separate -x and -X tests (the second works on $PATH).
And no other shell I know searches in $PATH. But then fvwm is not shell.

> So I think that  x,r,w,f,i,m are ok.

I really don't know, it is probably just my habit to write "-r file".

Regards,
Mikhael.