Subject: Re: fvwm2 Core dump info

From: Tim Phipps <[email-masked]>
Date: Wed, 02 Dec 1998 11:30:04 +0000

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

This seems to be a pretty generic bug in the way fvwm handles destroying
things in functions.  Is it possible to detect when fvwm is in the
middle of a function?  If so it might be possible to have the free()'s
diverted into a list when fvwm is processing a function and have the
list of free()' executed when fvwm becomes idle.  I know this sounds
like a bodge but it would let a function destroy itself.

Just wondering,
Tim.
--
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: Wed, 2 Dec 1998 13:35:07 +0100

> like a bodge but it would let a function destroy itself.

Perhaps we can do this. But we shouldn't do so close to the release.
In the end most people won't do what I do in the purify script.
After the release we should think of some way to allow this
(there is a bug report for DestroyFunc and DestroyMenu in Jitterbug
already. Seems it has to be extended to window destruction).

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: 02 Dec 1998 09:34:19 -0500

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

  dv> After the release we should think of some way to allow this
  dv> (there is a bug report for DestroyFunc and DestroyMenu in Jitterbug
  dv> already. Seems it has to be extended to window destruction).

I wrote a bug (#42) on the problems found with Recapture and Destroy in
a function.

-- 
-------------------------------------------------------------------------------
 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: Bob Woodside <[email-masked]>
Date: Thu, 3 Dec 1998 00:38:56 -0500 (EST)

Dominik Vogt <[email-masked]> wrote:
> > ...If so it might be possible to have the free()'s

	I agree.

> In the end most people won't do what I do in the purify script.

	...or I think we'd have heard howling for years!

> already. Seems it has to be extended to window destruction).

	Actually, there are several issues raised here. The general case
of window destruction within a function and the special case of function
self-destruction are definitely going to require a good deal of thought,
and probably some lively debate.

	However, for the special case of Recapture, I'd like to reiterate
my prior suggestion that Recapture should be able to tell Destroy to do
everything *except* actually free the FvwmWindow struct, and then be able
to pass the struct through to AddWindow to be reused. This is easy to do,
and has utility beyond the context of function processing. I'll eventually
need to do something like this anyway, to allow options to preserve certain
state information (that is in that struct) across a Recapture (as in my
old RecaptureRemembersIconPositions hack); and it will effectively close
this particular loophole.

- Bob

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 3 Dec 1998 12:03:45 +0100

On Thu, Dec 03, 1998 at 12:38:56AM -0500, Bob Woodside wrote:
> ... I'll eventually

Just be sure to write something in Jitterbug so we know
what will be done.

Dominik