To: atheos-developer@lists.sourceforge.net
Subject: Re: [Atheos-developer] Strange crash, repeatable...
From: Kurt Skauen <kurt@atheos.cx>
Date: 07 Aug 2001 19:11:57 +0200

Tord Jansson <tord.jansson@swipnet.se> writes:

> I think I have managed to isolate some strange crashes I've been experiencing 
> into a really minimal program.
> 
> On my computer, the following program freezes the screen (everything except 
> the mousepointer, I have to change into another screen to kill the processes 
> from bash) *every time* I try to close the program by clicking on "Close" in 
> the menu entry. It doesn't freeze if I close it by pushing the close button 
> on the window border though.

<SNIP> 
> int main( int argc, char * argv[] )
> {
> 	MyApplication * myApp;
> 	myApp = new MyApplication( argc, argv );
> 	myApp->Run();
> 	delete myApp;
> 	return 0;
> }
<SNAP>
 
> I have a single processor machine and the freezing happens *every* time for 
> me.
> 
> A similar thing happens to me in my full source code for Buttonz. I have a 
> window with just a menu bar (file, edit, help) and an extra empty view which 
> is removable. If I click on the "close window" entry in my file menu the 
> window closes just fine. But if I first remove the extra empty view (through 
> a menu alternative, using the method RemoveChild()) and THEN click on the 
> "close window" entry it freezes in exactly the same view.
> 
> Seems like atheos somehow is depending on there being more than just the 
> menubar in a window if you close it by sending M_QUIT from a menu entry... :-/
> 
> Unless I of course have made some really silly misstake with big 
> consequences, in which case I would be delighted to get a 
> correction...

You should not delete the application object. All os::Looper dervied
object's will delete themself when the message loop is terminated.
Deleting it will most likely cause it to crash since the object will
be deleted twice.

A general tips when something crash is to take a look in
/var/log/kernel ("tail [-f] -n 200 /var/log/kernel"). The kernel will
dump the call-stack of the crashed thread and that will often give a
good idea about why it crashed (or at least where).


The reason the entire desktop might hang is that the menu window steal
all input while it's open and in this case it's a great risk that the
application thread crash before the menu manage to close itself. Since
some of the application's threads are still alive the appserver won't
automatically close the window and remove the menu and the desktop
appear locked. But like you said it is possible to move to another
desktop and kill the remaining threads to get rid of the menu and
regain controll over the desktop.



-- 
Kurt Skauen. ( http://www.atheos.cx/ )

"There are two kinds of people, those who do the work and those who take
credit. Try to be in the first group, there is less competition there." __
Indira Gandhi 


_______________________________________________
AtheOS-developer mailing list
AtheOS-developer@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/atheos-developer