Subject: Re: FVWM: Premature close of OpenInterface GUI

From: Dan Espen <[email-masked]>
Date: Sat, 14 Dec 2002 22:05:22 -0500

Hi,

  I think I can pretty confidently say Fvwm is not shutting down
your application.  I don't know why it closes, but I might have
some hints.

  I have a few different traces.  This one is from Fvwm.
It shows every event Fvwm recieves from X, and every call to
XUnmapWindow or XDestroyWindow that Fvwm makes, and some tracing
in Fvwm's routines for adding and destroying windows.

Fvwm event: UnmapNotify
HandleUnmapNotify: calling destroy_window 815F200, event 1800026, window 1800026, Root 26, send_event 0
destroy_window: entered
destroy_window: About...
Called XUnmapWindow in ../../fvwm2_5_6/fvwm/add_window.c at 3011
Called XDestroyWindow in ../../fvwm2_5_6/fvwm/add_window.c at 1147
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: LeaveNotify
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: 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 815E520, event 1800012, window 1800012, Root 26, send_event 0
destroy_window: entered
destroy_window: RAID Manager - dog.bert.sun.fi
Called XUnmapWindow in ../../fvwm2_5_6/fvwm/add_window.c at 3011
Called XDestroyWindow in ../../fvwm2_5_6/fvwm/add_window.c at 1147
Fvwm event: DestroyNotify
HandleDestroyNotify: calling destroy_window
destroy_window: entered
Fvwm event: DestroyNotify
HandleDestroyNotify: calling destroy_window
destroy_window: entered

Between the time the About window closes, and the main window closes
there are multiple entries into Fvwm's destroy_window function,
but it never calls XUnmapWindow or XDestroyWindow.  The first
thing Fvwm knows about the main window is when it recieves an
UnmapNotify.  So the main window decides to close on its own.

Then I have a trace using this command:

truss -f -t'!all' -u:: /usr/lib/osa/bin/rm6

This traces all shared library calls:

13815:        <- libX11:XCheckTypedEvent() = 0
13815:      <- libndvgm:EventNatProcessPendingInvals() = 0xff0ebe08
13815:      -> libndvgm:S_ResetArrayIfAllNull(0xf37e8, 0x0, 0x0, 0x0)
13815:      <- libndvgm:S_ResetArrayIfAllNull() = 0xf37e8
13815:      -> libndvgm:DrawFlush(0xf37e8, 0x0, 0x0, 0x0)
13815:      -> libX11:XFlush(0x93d50, 0x0, 0x0, 0xff0ebe08)
13815:        -> libX11:_XFlush(0x93d50, 0x0, 0x0, 0x0)
13815:        -> libX11:_XFlushInt(0x93d50, 0x0, 0x0, 0x0)
13815:        <- libX11:_XFlush() = 0x93d50
13815:      <- libndvgm:DrawFlush() = 0x93d50
13815:    <- libndvgm:EVENT_ProcessInval() = 0xe5d30
13815:  <- libndvgm:EVENT_MainLoop() = 4
13815:  -> libndgw:GW_LibExit(0x4, 0x5cbb8, 0x0, 0x1)
13815:  -> libndtkit:TKIT_LibExit(0x4, 0x5cbb8, 0x0, 0x0)
13815:    -> libndcore:PTR_Dispose(0xcc770, 0xcc770, 0x0, 0x0)
13815:    -> libndcore:S_Dispose(0xcc770, 0xcc770, 0x0, 0x0)
13815:      -> libndcore:S_free(0xcc768, 0x107, 0x0, 0x0)
13815:        -> libc:free(0xcc768, 0x0, 0x0, 0x0)
13815:          -> libc:mutex_lock(0xfeb3e498, 0x77510, 0x0, 0xfeb3a000)
13815:          -> libc:_return_zero(0xfeb3e498, 0x77510, 0x0, 0xfeb3a000)
13815:          <- libc:mutex_lock() = 0
13815:          -> libc:_free_unlocked(0xcc768, 0x77510, 0x0, 0xfeb3a000)
13815:          <- libc:_free_unlocked() = 0xcc768
13815:        -> libc:mutex_unlock(0xfeb3e498, 0x0, 0x0, 0x0)
13815:        -> libc:_return_zero(0xfeb3e498, 0x0, 0x0, 0x0)
13815:        <- libc:free() = 0
13815:      <- libndcore:S_free() = 0xcc768
13815:    <- libndcore:PTR_Dispose() = 0xcc770
13815:  -> libndvgm:VGM_LibExit(0x4, 0x5cbb8, 0x0, 0x0)
13815:    -> libndvgm:S_ReleaseCriticalResources(0x0, 0x0, 0x0, 0x0)
13815:      -> libndvgm:DSPLY_Exit(0x1058, 0x1, 0x0, 0x0)
13815:        -> libndres:RES_SetLoadConstructProc(0xfeeae9a8, 0x0, 0x0, 0x0)
13815:        <- libndres:RES_SetLoadConstructProc() = 0xfeeae9a8
13815:      -> libndvgm:DsplyNatExit(0x1058, 0x1, 0x0, 0x0)

This one is not so easy to understand, but before this
section, I can saw X just carrying on its normal processing.
Then libndvgm:EVENT_ProcessInval returns to the main loop
in the library and comes up with a 4 return code.
Everything after this is the library shutting down the application.

This might be a little clearer is you look at the output from
this truss command:

truss -f -t'!all' -ua.out /usr/lib/osa/bin/rm6

13829:      <- S_AboutWindowNfy() = 0x11f4a0
13829:      -> S_launcher_mainNfy(0xf8800, 0x6d, 0xe4710, 0x4)
13829:        -> S_launcher_mainNfy(0xf8800, 0xc6, 0x0, 0x0)
13829:          -> S_launcher_mainNfy(0xf8800, 0xb7, 0x0, 0x0)
13829:          <- S_launcher_mainNfy() = 0xf8800
13829:        <- S_launcher_mainNfy() = 0xf8800
13829:        -> S_launcher_mainNfy(0xf8800, 0xc6, 0x0, 0x0)
13829:          -> IconAreaNotify(0xf9800, 0x6d, 0xb3a40, 0x40000000)
13829:          <- IconAreaNotify() = 0xf9800
13829:          -> IconLabelNotify(0xf99c0, 0x6d, 0xe3cd0, 0x40000000)
13829:          <- IconLabelNotify() = 0xf99c0
13829:          -> IconAreaNotify(0xf9b18, 0x6d, 0xb3a40, 0x40000000)
13829:          <- IconAreaNotify() = 0xf9b18
13829:          -> IconLabelNotify(0xfd0e0, 0x6d, 0xe3cd0, 0x40000000)
13829:          <- IconLabelNotify() = 0xfd0e0
13829:          -> IconAreaNotify(0xfdd20, 0x6d, 0xb3a40, 0x40000000)
13829:          <- IconAreaNotify() = 0xfdd20
13829:          -> IconLabelNotify(0xfde90, 0x6d, 0xe6488, 0x40000000)
13829:          <- IconLabelNotify() = 0xfde90
13829:          -> IconAreaNotify(0xfe3f8, 0x6d, 0xb3a40, 0x40000000)
13829:          <- IconAreaNotify() = 0xfe3f8
13829:          -> IconLabelNotify(0xfe568, 0x6d, 0xe3cd0, 0x40000000)
13829:          <- IconLabelNotify() = 0xfe568
13829:        <- S_launcher_mainNfy() = 0xf8800
13829:      <- S_launcher_mainNfy() = 0xf8800
13829:      -> APP_Exit(0x4, 0x5cbb8, 0x0, 0x0)
13829:      <- APP_Exit() = 4
13829:    <- APP_Main() = 0
13829:  <- main() = 0
13829:  -> _fini(0xfeb3fdf8, 0xfeb3fdd0, 0x1, 0x1571c)
13829:  <- _fini() = 0xfeb3fdf8

This is tracing function calls in the main.
It shows the main seeing the About window closing, then
the main looks like its repainting its icons.  It looks to
me like the main then becomes aware of the return code
4 from the toolkit its using and exits its main loop
with return code 4.
Thats the APP_Main() = 4.
Then the main exits with return code 0.

Naturally, I'm making some guesses about whats going on
inside libndvgm.  Based on the function names it looks like
some kind of GUI toolkit, but Google didn't turn up anything.

I think the GUI toolkit doesn't like something that goes on.
Its hard to say what.  It has something to do with the combination
of fvwm and DISPLAY :0, but theres nothing obvious in these
traces.  My guess is that the return code 4 is important.

The main app, the launcher, is interesting.
When it comes up, it must set a hint saying it doesn't want
a titlebar because it doesn't display a titlebar for me.
Whats interesting, is there is no close button in the app
and no menu to use to close the app.  It doesn't want a titlebar,
so it doesn't expect to be closed down with the titlebar close button
either.  So how does this thing want to be closed down?

Well, thats all I have.  Sorry I can't tell you exactly whats
wrong or make some adjustment to Fvwm to fix it.  At least
not yet.

I don't see how I can make any more progress with this without
some help from the rm6 developers.

-- 
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: Dominik Vogt <[email-masked]>
Date: Mon, 16 Dec 2002 12:03:32 +0100

> your application.  I don't know why it closes, but I might have

[snip]

> some help from the rm6 developers.

And I think we should not waste our time debugging broken
applications.  I'd dispose of the problem by sending a bug report
and hope they will fix it.

Bye

Dominik ^_^  ^_^