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