bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #24785] Application not quitting properly on some platforms.


From: Fred Kiefer
Subject: [bug #24785] Application not quitting properly on some platforms.
Date: Sun, 16 Nov 2008 13:52:53 +0000
User-agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.9 (like Gecko) SUSE

Follow-up Comment #2, bug #24785 (project gnustep):

Some more information from the mailing list. Sadly I never did get a reply to
my last mail.

Gregory Weston wrote:
> > In article <mailman.1052.1224018351.25473.discuss-gnustep@gnu.org>,
> >  Marko Riedel <markoriedelde@yahoo.de> wrote:
> > 
>> >> the environment is KDE 3.5 (sorry, I had no choice in the matter), but
the 
>> >> same problem occurs with WindowMaker. The application is not
document-based 
>> >> and does have an application delegate and applicationShouldTerminate:
is 
>> >> invoked. As I did not subclass NSApplication I don't know whether 
>> >> replyToApplicationShouldTerminate: gets called (this is not a delegate
method 
>> >> according to developer.apple.com).
> > 
> > Correct; it's not a delegate method. It's a message that's sent to the 
> > NSApplication instance at some point after the delegate's 
> > applicationShouldTerminate: returns NSTerminateLater. It's a way to 
> > conditionalize termination on uncached things like user input. You 
> > really shouldn't need to send this message if applicationShouldTerminate

> > returns any other defined value.
> > 

All of this is true, but this method
(replyToApplicationShouldTerminate:) gets also called internally from
terminate:. What I was interesting in would be to find out how far this
methods gets progressed. This could be checked by adding a few NSLog()
statements and recompiling gui. I know this is asking much, but I am not
able to reproduce this behaviour here and so I need to get more
information from a machine where it actually fails.

Adding something like
NSLog(@"replyToApplicationShouldTerminate: called with %d isrunning %d",
shouldTerminate, _app_is_running);

as the first line and then ever other line something like
NSLog(@"replyToApplicationShouldTerminate: now at line %d", __LINE__);

This could provide the needed information and help solve the mysterious
issue.

Fred


If the process really hangs somewhere down in
replyToApplicationShouldTerminate:
it might be sufficient to attach gdb to it and then use the where command
to get a backtrace.

Wolfgang



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24785>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]