Subject: Re: FVWM: Premature close of OpenInterface GUI

From: Dan Espen <[email-masked]>
Date: Thu, 12 Dec 2002 11:07:04 -0500

I've been trying to debug this, but I'm pretty much stuck.
I've been working off the workers list, but in this case,
I'm copying the list since I'm out of ideas, and I see something
pretty strange.

The original problem is an "Openinterface" application from Sun
that seems to exit when one of its child windows closes.
Tomi suspects that Fvwm is telling the application to close.

The last 4 tests I've run fail to duplicate the problem.
I don't have any reason to suspect that additional runs
will make the problem come back.

I did some Google searches for "Openinterface" and I fail to
find anything that explains what it is.

I also searched for "rm6" and "fvwm" and didn't turn up anything
useful.

Here's the thing that's strange:

The last test I did, I ran rm6 inside an Xnest window with nothing
else active inside the Xnest window, not even Fvwm.  Ie. I ran
rm6 without a window manager.

The strange thing is, rm6 came up with a border and titlebar.
Using the border, I was able to resize the window, and clicking
on the border, I got a popup menu that looked to me like an
mwm menu.  I did some "ps" commands and wasn't able to find any
window manager running.  Running this way, I wasn't able to get
the status popup to show, but I was able to get the about screen
to come up.  (Also with a border.)
I wasn't able to duplicate the problem this way
though.

>From this, I conclude that rm6 is way too involved with the
window manager.  I don't know what its doing to put borders
on itself, but it appears to be detecting the absence of
the window manager and doing something.

I think we need more information about Openinterface.

-- 
Dan Espen                           E-mail: [email-masked]
--
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: Dan Espen <[email-masked]>
Date: Thu, 12 Dec 2002 15:46:18 -0500

> I'm copying the list since I'm out of ideas, and I see something

Further developments:

I find I can't create the problem in an Xnest window,
but I can on :0.  Thats seems very consistent.

Using prints, I see that HandleUnmapNotify calls
destroy_window leading to the window the main window
being destroyed.

HandleUnmapNotify doesn't seem to get called inside Xnest.

I think what I need to do is print more of the information
about the event.  Right now, I have no idea how to do that,
or what to look for,
so I have to do more research.  Of course, hints would be
appreciated.

Doesn't an Unmap event indicate the application has unmapped
itself?  Looking at the logic in HandleUnmapNotify, it looks
like its not that simple.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 13 Dec 2002 10:12:08 +0100

> so I have to do more research.  Of course, hints would be

Add this after the "if (!fw)" clause in HandleUnmalNotify():

  fprintf(stderr,
	"hun: w=0x%08x f=0x%08x, synthetic=%d '%s'\n",
	(int)te->xunmap.event, te->xunmap.send_event,
	(int)fw, (fw) ? fw->visible_name : "(null");

te->xunmap.event is the client window id that was unmapped.  If
te->xunmap.send_event is true, the client requested transition to
withdrawn state.

> itself?

No, fvwm gets an XUnmapNotify when the X server unmaps a client
window.  It does not matter why the window was unmapped..  I can't
think of anything else but to find all places where
XUnmapWindow(), XDestroyWindow() or XWithdrawWindow() is called for
a client window throughout the fvwm core and print debug output for
each (et least the window id and the title).  But to be honest, I
don't expect much to come out of the whole debug session.  Since
you said that the app tries to be its own window manager, I
strongly suspect that its doing something terribly wrong.

It may help to watch the events flying around prior to the window
being unmapped.

> Looking at the logic in HandleUnmapNotify, it looks

Bye

Dominik ^_^  ^_^

---

From: Tomi Vainio - Sun Finland - <[email-masked]>
Date: Fri, 13 Dec 2002 11:25:55 +0200

> but I can on :0.  Thats seems very consistent.
When you said that you see problem only with :0 and I did some testing
also and found out that's true.  At work I'm using dual screen system
and the problem only occurs with :0.0 not with :0.1

I tried fvwm 1.2.4r and it's also just fine.

  Tomppa

---

From: Tomi Vainio - Sun Finland - <[email-masked]>
Date: Fri, 13 Dec 2002 16:24:57 +0200

Dan Espen writes:
 > Do you mean it works on both :0.0 and :0.1?
 > 
Yes this is true!

  Tomppa

---

From: Dan Espen <[email-masked]>
Date: Fri, 13 Dec 2002 08:20:29 -0500

> te->xunmap.send_event is true, the client requested transition to

Gee, maybe I'm not hopeless, I already have all that.
Here's what I gathered:

AddWindow: entered
AddWindow: window 8164FE0, window name is RAID Manager - dog.bert.sun.fi
AddWindow: entered
AddWindow: window 815FBD0, window name is About...
HandleUnmapNotify: calling destroy_window 815FBD0, event C00026, window c00026, Root 26, send_event 0
destroy_window: entered
destroy_window: About...
HandleDestroyNotify: calling destroy_window
destroy_window: entered
HandleDestroyNotify: calling destroy_window
destroy_window: entered
HandleDestroyNotify: calling destroy_window
destroy_window: entered
HandleDestroyNotify: calling destroy_window
destroy_window: entered
HandleDestroyNotify: calling destroy_window
destroy_window: entered
HandleUnmapNotify: calling destroy_window 8164FE0, event C00012, window c00012, Root 26, send_event 0
destroy_window: entered
destroy_window: RAID Manager - dog.bert.sun.fi
HandleDestroyNotify: calling destroy_window
destroy_window: entered
HandleDestroyNotify: calling destroy_window
destroy_window: entered
HandleDestroyNotify: calling destroy_window
destroy_window: entered

The debug statement in HandleUnmapNotify looks like this:

	fprintf(stderr,"HandleUnmapNotify: calling destroy_window %X, event %X, window %X, Root %X, send_event %X\n",
		(int)fw,(int)te->xunmap.event,
		(int)te->xunmap.window,
		(int)Scr.Root,
		(int)te->xunmap.send_event);

What you labeled as "synthetic" I've got labeled as "window".
I wanted to know if it was a synthetic event, but I didn't know
how to do that.  What value would fw have if it was synthetic?

In destroy_window, theres one statment showing entry and another
when fw is non-zero.

> each (et least the window id and the title).

OK, I think you are saying that there are other places a window
can get unmapped/destroyed/withdrawn by fvwm other than destroy_window.
I'll try to find all the other places and see if I can trace them.

> But to be honest, I

Good.  Thats my feeling too.
The actual application executable has a name that ends in .EXE,
(a sure sign of trouble).  But I don't think this is another one
of those Mainsoft applications (like Rational Rose).

> It may help to watch the events flying around prior to the window

We don't seem to have any debug logic that produces a trace of events.
It seems like it would be pretty useful.

---

From: Dan Espen <[email-masked]>
Date: Fri, 13 Dec 2002 09:01:50 -0500

> and the problem only occurs with :0.0 not with :0.1

Same here.  It has a problem on Linux vt7 (:0),
but works fine on Linux vt8 (:1).

BTW, in my last email, I misspoke, the executable ends in
.exec, not .EXE.  (I'll wake up soon.)  At least its not guilty
of the sin of trying to work under Windows, but that doesn't
explain why its trying to be its own window manager.

---

From: Dan Espen <[email-masked]>
Date: Fri, 13 Dec 2002 23:30:34 -0500

> > Dan Espen <[email-masked]> writes:
...
> It may help to watch the events flying around prior to the window

I don't think just the events help, its not clear where they
originate:

Fvwm event: UnmapNotify
HandleUnmapNotify: calling destroy_window 8163818, event 1800026, window 1800026, Root 26, send_event 0
destroy_window: entered
destroy_window: About...
Fvwm event: FocusOut
Fvwm event: LeaveNotify
Fvwm event: UnmapNotify
Fvwm event: FocusIn
Fvwm event: PropertyNotify
Fvwm event: PropertyNotify
Fvwm event: PropertyNotify
Fvwm event: ReparentNotify
Fvwm event: ReparentNotify
Fvwm event: UnmapNotify
Fvwm event: VisibilityNotify
Fvwm event: VisibilityNotify
Fvwm event: LeaveNotify
Fvwm event: EnterNotify
Fvwm event: EnterNotify
Fvwm event: DestroyNotify
HandleDestroyNotify: calling destroy_window
destroy_window: entered
Fvwm event: PropertyNotify
Fvwm event: PropertyNotify
Fvwm event: PropertyNotify
Fvwm event: PropertyNotify
Fvwm event: FocusOut
Fvwm event: FocusIn
Fvwm event: PropertyNotify
Fvwm event: PropertyNotify
Fvwm event: PropertyNotify
Fvwm event: PropertyNotify
Fvwm event: DestroyNotify
HandleDestroyNotify: calling destroy_window
destroy_window: entered
Fvwm event: PropertyNotify
Fvwm event: PropertyNotify
Fvwm event: PropertyNotify
Fvwm event: DestroyNotify
HandleDestroyNotify: calling destroy_window
destroy_window: entered
Fvwm event: DestroyNotify
HandleDestroyNotify: calling destroy_window
destroy_window: entered
Fvwm event: DestroyNotify
HandleDestroyNotify: calling destroy_window
destroy_window: entered
Fvwm event: UnmapNotify
HandleUnmapNotify: calling destroy_window 8161308, event 1800012, window 1800012, Root 26, send_event 0
destroy_window: entered
destroy_window: RAID Manager - dog.bert.sun.fi
Fvwm event: FocusOut
Fvwm event: LeaveNotify
Fvwm event: DestroyNotify

I could add window id to the events that its appropriate for,
but I don't know that it would be any clearer.  Still, its
educational to see all this stuff.

It would be neat to be able to turn a trace  like this off and on with
a special keypress or buttonpress.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 13 Dec 2002 18:08:27 +0100

> HandleDestroyNotify: calling destroy_window

So, either fvwm unmapped the window or the application unmapped
it.  But the application definitely did not ask fvwm to withdraw
the window.  Do you get an XDestroyNotify event for the window
too?

> how to do that.  What value would fw have if it was synthetic?

If the client window has a frame is should be a pointer to the
window structure, and NULL otherwise.  The send_event member does
not affect fw.

> I'll try to find all the other places and see if I can trace them.

I don't see any XWithdrawWindow() and XDestroyWindow() calls (as
expected), but there are several XUnmapWindow() calls.  I forgot
to mention XReparentWindow(), which unmaps the window if it was
already mapped.

Perhaps you could just comment out all XUnampWindow() calls on the
client window and all Reborder() calls for the moment.  If this
still happens we can safely assume that the application unmapped
or destroyed the window itself.

> It seems like it would be pretty useful.

I often put in a lot of debug statements, but in general I am only
interested in a few events, but with very detailed output.  One
big debug switch wouldn't work too well - we'd need more control
over the debug level and the verbosity of each event type.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Mon, 16 Dec 2002 10:59:30 -0500

This mail seems to have gone thru a time warp, you sent it Friday,
but I'm reading it on Monday.

> or destroyed the window itself.

I think thats all resolved now, but I thought I'd mention,
I put a macro for XUnmapWindow in fvwm.h, remapped the function
call to print the __FILE__ and __LINE__ information, then
invoked MyXUnmapWindow where the real XUnmapWindow was called.
It seemed to work pretty well.

> over the debug level and the verbosity of each event type.

Well, I did it with one big switch statement.  It worked pretty
well.  I don't know if I should bother to commit it as ifdef'd debug
code or not, its not that hard to recreate.  I agree, most often
its just one or 2 events that are of interest.  I think I'll just
hold onto it.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 16 Dec 2002 17:14:58 +0100

On Mon, Dec 16, 2002 at 10:59:30AM -0500, Dan Espen wrote:
> I think thats all resolved now,

Damn, I sent that mail on friday.

> but I thought I'd mention,

Bye

Dominik ^_^  ^_^

---

From: Jason L Tibbitts III <[email-masked]>
Date: 16 Dec 2002 10:44:28 -0600

>>>>> "DV" == Dominik Vogt <[email-masked]> writes:

DV> Damn, I sent that mail on friday.

It only recently traveled from schlund.de to mail.gmx.net:

Received: from eth0.gw-ma-b.core.es.ka.schlund.de (HELO erdbeere.schlund.de) (195.20.224.7)
  by mail.gmx.net (mp009-rz3) with SMTP; 16 Dec 2002 10:21:33 -0000
Received: from luthien by erdbeere.schlund.de with local
	id 18MtIZ-0004bH-00
	for <[email-masked]>; Fri, 13 Dec 2002 18:08:27 +0100

 - J<