Subject: Re: fvwm2 Core dump info

From: Bob Woodside <[email-masked]>
Date: Tue, 1 Dec 1998 23:19:20 -0500 (EST)

[email-masked] (Paul D. Smith) wrote:
> It's the first Recapture that seems to be causing the problem.
> ...
> Boom.
> 
> Now the global Tmp_win pointer and all the values of tmp_win,
> etc. passed as arguments to ComplexFunction, etc. are invalid; they're
> pointing to freed memory.  The next attempt to dereference them will
> fail.
>

	Ouch! This looks like an accident that's been waiting to happen
for a long time - both Recapture and Destroy invoked from a function
seem to be hazardous.

> 
> Not sure what the story is _supposed_ to be here, but it seems like that
> Destroy isn't such a good idea?  Or is the "current" window supposed to
> be protected somehow?  Or something?

	Not that I can see. Of course, "current window" becomes a somewhat
nebulous notion when FVWM starts calling itself with fake events, as
happens in Recapture.

	I think that one reason we don't see it happening all the time
has to do with the memory allocation strategies used in different systems.
As soon as the window is destroyed, Recapture re-adds it; I suspect that
those of us who've not been able to duplicate this have had the exact
same memory area immediately re-allocated as the "new" FvwmWindow struct
for the recaptured window, and nobody is the wiser. If that ever fails
to happen, er, boom!

	Another likely reason we don't see it much is that most people
probably don't have Destroy in a function, but rather have the single
built-in command bound to a mouse action or a menu item; and Recapture
perhaps isn't used that often in very complex functions.

	I think there are some things we could do to prevent the situation,
but we may be a little late into the release cycle to do them now.

	My first thought is to add a Boolean Reuse calling arg to Destroy
to tell it not to free the struct, and an *FvwmWindow arg to AddWindow
and friends to tell them to reuse the already allocated structure.
Certain functions, like Recapture, could supply these args to protect
themselves...or, rather, their callers.

	The Destroy command probably needs some special handling if
invoked from a function, to prevent it from destroying the window with
which ExecuteFunction was invoked...something like

  if (tmp_win == NoDestroyWin) return;  /*  No-op destroy self  */

- Bob

--
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].