On Sun, May 18, 2003 at 08:27:12PM +0200, Olivier Chapuis wrote: > On Sun, May 18, 2003 at 01:12:15PM -0500, FVWM CVS wrote: > > 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 > > Again Valgrind help as well as fvwm-themes and purify.fvwm2rc > > > * Fixed a memory leak (a FvwmWindow !) when a window is not destroyed > > 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?
Use a separate list. Windows schedules for destruction *must not* show up in the regular window list. > > * Fixed the default buttons memory leak and > > * Removed inconsistent #if 0 code and comments about leak and MiniIcon > > decor style > > 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? 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. > > * Limited the depth of function to MAX_FUNCTION_DEPTH (=512). This fixes > > cores dumps with "recursive" functions Good idea. > [snip] > > > * 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. > 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.) Bye Dominik ^_^ ^_^ -- 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]
