bugGNUstep - Bugs: bug #24785, Application not quitting properly...

Group
 
 

bug #24785: Application not quitting properly on some platforms.

Submitter:  Gregory John Casamento <gcasa>
Submitted:  Sat 08 Nov 2008 11:03:33 PM UTC
   
 
Category:  Gui/AppKit Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  gcasa
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 16 Dec 2008 02:07:19 PM UTC, comment #22: 

works for me on several platforms and applications, I consider that it works for me. If it still happens for somebody, he should reopen the bug or file a new one.

Riccardo Mottola <rmottola>
Group Member
Sat 06 Dec 2008 01:16:11 PM UTC, comment #21: 

Wolfgang,

Nevertheless, it is getting this problem on the standard compiler for NetBSD (the latest release) which is 4.2.1.   It needs to work there.  We can't ask people to build or download a new compiler simply because GNUstep happens to hit a bug in it.

Richard,

I think the mask is definitely a better solution than the double casting.

GC

Gregory John Casamento <gcasa>
Group administrator
Fri 05 Dec 2008 10:08:42 PM UTC, comment #20: 

Ah ... I thought BOOL was typedef'ed as int.  As it's an unsigned char, the cause of the problem (and reason the fix works) is clear.

However, I think instead of the double cast, we should explicitly mask the return result with 0xff and add a comment to say that old code may only set the low byte of the result, so we need to mask out the top bytes.  IMO this would make the whole issue much clearer if/when someone looks at the source in future.

Richard Frith-Macdonald <CaS>
Group Member
Fri 05 Dec 2008 09:36:43 PM UTC, comment #19: 

I did run it through the debugger, but on all machines I tested, the call returns the value 1 and not 153 million something. So it might be that your compiler sets only the lower 8 bits of the result register in the -applicationShouldTerminate: delegate method since BOOL is typedef'd as unsigned char in <objc/objc.h>.

Wolfgang Lux <wlux>
Fri 05 Dec 2008 07:02:26 PM UTC, comment #18: 

Given that the return value before the change is coming back as 153 million something, and after the change it's coming back as expected (0,1,2) it DOES fix something.

I encourage you to run it through the debugger and check the value that comes back from the delegate call to applicationShouldTerminate: before and after the change.

Use SystemPreferences or FTP.app (in GAP on nongnu savannah) to test this.

I realize that looking at the change, it doesn't seem like it should work or even change the semantics of what is happening because:

1) the enum sets the values explicitly...
2) it is coercing it back into the appropriate type.

but, from observation, it does work since applications which were previously not quitting are quitting correctly after the change.

GC

Gregory John Casamento <gcasa>
Group administrator
Fri 05 Dec 2008 05:47:36 PM UTC, comment #17: 

In fact, I'm going with Richard here and am very skeptical that the change in r27195 does fix anything at all. I've looked at the assembler output of NSApplication.m for x86 and ppc with three different compiler versions and the only difference for all of them is one additional instruction that sets the higher order 24 bits of the result register (r3 on ppc, eax on x86) to zero after the change. Given the legitimate values of type BOOL (0,1) and NSApplicationTerminateReply (0,1,2) this does not make any difference at all.

Wolfgang Lux <wlux>
Fri 05 Dec 2008 04:34:20 PM UTC, comment #16: 

It seems like there is some confusion about what this bug report is about. The original post only noted that applications were not properly quitting after selecting Quit from the menu. This is the same that happened to me and I've been able to track this down to the notification issue (see comment #6 below).

Wolfgang Lux <wlux>
Fri 05 Dec 2008 03:52:00 PM UTC, comment #15: 

This is a different problem than the one I fixed.   The problem I found was an issue with interpreting a return value.  This is an issue with sending a notification.

Gregory John Casamento <gcasa>
Group administrator
Fri 05 Dec 2008 02:21:51 PM UTC, comment #14: 

I'm sorry to say, but I've just hit the issue again (this time after upgrading to r27208, i.e., including the changes from Dec. 3rd). Again, the code hangs in the local event loop run by NSWorkspace's distributed notification center while positing NSWorkspaceDidTerminateApplicationNotification. So the bug has not been fixed by now.

Incidentally, CPU usage is at 100% until I attach the debugger. When I continue the program in the debugger CPU usage remains low.

Wolfgang Lux <wlux>
Wed 03 Dec 2008 01:27:53 PM UTC, comment #13: 

It's probably because the enum values are set to the BOOL values when the enumerated type is initialized.   I believe it indicates either a compiler bug or an alignment problem of some sort.

The fix does correct the issue on NetBSD and works properly on other platforms we tested yesterday.

Gregory John Casamento <gcasa>
Group administrator
Wed 03 Dec 2008 08:06:58 AM UTC, comment #12: 

As far as I can see, the double coercion should do nothing ... so I would expect that any 'fix' is purely coincidental and we should remove both casts.  However, perhaps someone can point to some mechanism whereby this change would fix something?

Richard Frith-Macdonald <CaS>
Group Member
Wed 03 Dec 2008 07:33:57 AM UTC, comment #11: 

Did you check that your double conversion also works with a return value of NSTerminateLater?
You see, I am too unsure what a conversion to BOOL actually does. (Being spoiled by Java day time programming, I mistrust a compiler) Most likely it wont change the value at all, but as you had problems with other values, we should make sure the third one is handled correctly as well.

Fred Kiefer <FredKiefer>
Group Member
Wed 03 Dec 2008 12:44:34 AM UTC, comment #10: 

We need to do double coercion here since some version of the compiler will get confused due to the differences in how enum is implemented on various platforms.  This ensures that the return type is handled properly in all cases.

We tried the fix on a number ofdifferent apps that Riccardo was having issues with.  Could anyone who has been having this problem please test their apps and comment.

I am moving this to Fixed/In Test.

Thanks, GC

Gregory John Casamento <gcasa>
Group administrator
Mon 01 Dec 2008 02:36:19 PM UTC, comment #9: 

Not very likely, athough it might be releated. You were testing on a 64-bit machine and your problem was with the "did launch" notification. I am getting a problem on the terminate notification and am using a 32-bit machine. Most of all, I already have Richards new code installed, that is why a get a proper exception in the first place.

But I am still unsure, whether my problem is related to the problem reported here, so perhaps I should not insist to much on it here.

Fred Kiefer <FredKiefer>
Group Member
Mon 01 Dec 2008 02:05:53 PM UTC, comment #8: 

Fred,

Looks like you get the same problem I had last week, Richard fixed it, see bug report #24939

Quentin.

Quentin Mathé <qmathe>
Group Member
Sat 29 Nov 2008 05:36:42 PM UTC, comment #7: 

Thank you for this information. Now at least we ahve an idea why this strange behaviour could happen.

I am not sure whether this is related, but after Richards patch to better report exceptions I did get the following when closing a process:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb73c38d0 (LWP 9905)]
0xffffe430 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb76ac900 in raise () from /lib/libc.so.6
#2  0xb76ae238 in abort () from /lib/libc.so.6
#3  0xb7cc0522 in _NSAppKitUncaughtExceptionHandler (exception=0x8560960)
    at NSApplication.m:148
#4  0xb7971a53 in callUncaughtHandler (value=0x8560960)
    at NSException.m:732
#5  0xb79721d1 in -[NSException raise] (self=0x8560960, _cmd=0xb7fa04c8)
    at NSException.m:867
#6  0xb7e5bd99 in -[_GSWorkspaceCenter postNotification:] (
    self=0x86319d0, _cmd=0xb7fa04e8, aNotification=0x857a8d8)
    at NSWorkspace.m:336
#7  0xb7e5beb5 in -[_GSWorkspaceCenter postNotificationName:object:userInfo:] (self=0x86319d0, _cmd=0xb7f05898, name=0xb7faacd0, object=0x8631750,
    info=0x857a8a8) at NSWorkspace.m:353
#8  0xb7cca52c in -[NSApplication replyToApplicationShouldTerminate:] (
    self=0x82473d8, _cmd=0xb7f05ca0, shouldTerminate=1 '\001')
    at NSApplication.m:3285
#9  0xb7cca2d0 in -[NSApplication terminate:] (self=0x82473d8,
    _cmd=0xb7fa97f8, sender=0x8610c60) at NSApplication.m:3255
---Type <return> to continue, or q <return> to quit---
#10 0xb7aac92f in L10 ()
   from /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.17
#11 0x082473d8 in ?? ()
#12 0xb7a6d3c3 in GSFFCallInvokeWithTargetAndImp (_inv=0x857e2d8,
    anObject=0x82473d8, imp=0xb7cca147 <-[NSApplication terminate:]>)
    at GSFFCallInvocation.m:709
#13 0xb7a6d78c in -[GSFFCallInvocation invokeWithTarget:] (
    self=0x857e2d8, _cmd=0xb7f05a48, anObject=0x82473d8)
    at GSFFCallInvocation.m:779
#14 0xb7cc6e25 in -[NSApplication sendAction:to:from:] (self=0x82473d8,
    _cmd=0xb7f50080, aSelector=0xb7fa97f8, aTarget=0x82473d8,
    sender=0x8610c60) at NSApplication.m:2020
#15 0xb7d8cb87 in -[NSMenu performActionForItemAtIndex:] (self=0x8609cc8,
    _cmd=0xb7f52950, index=17) at NSMenu.m:1141
#16 0xb7d95d4e in -[NSMenuView trackWithEvent:] (self=0x86f1e00,
    _cmd=0xb7f529c0, event=0x84051f0) at NSMenuView.m:1606
#17 0xb7d95ebf in -[NSMenuView mouseDown:] (self=0x86f1e00,
    _cmd=0xb7f9d158, theEvent=0x824aab8) at NSMenuView.m:1651
#18 0xb7e52a75 in -[NSWindow sendEvent:] (self=0x861e8a0,
    _cmd=0xb7f059e8, theEvent=0x824aab8) at NSWindow.m:3561
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) up 6
#6  0xb7e5bd99 in -[_GSWorkspaceCenter postNotification:] (
    self=0x86319d0, _cmd=0xb7fa04e8, aNotification=0x857a8d8)
    at NSWorkspace.m:336
336               [localException raise];
(gdb) p [[localException name] cString]
$1 = 0x8451f60 "NSInternalInconsistencyException"
(gdb) p [[localException reason] cString]
$2 = 0x86feb28 "registration with registered client"


To me this looks like a problem with gdnc, but it could be completely unreleated.

Fred Kiefer <FredKiefer>
Group Member
Sat 29 Nov 2008 04:54:56 PM UTC, comment #6: 

Apparently, I have hit this issue (for the first time) as well. This was for SWKBrowser from simplewebkit on Mac OS X with gnustep-base at r27131 and gnustep-gui at 27137 (both from the trunk). I have attached a stack trace for the hanging process. Obviously, the problem occurs while posting the NSWorkspaceDidTerminateApplicationNotification via NSWorkspace's notification center, which enters its own event loop and seems to be waiting for some event it doesn't receive.

In case it matters, I have GWorkspace running. Also this happened only upon starting SWKBrowser for the third of fourth time. In fact, I just started SWKBrowser again and it did terminate normally again.

I'll try to keep the hanging process running if further information is necessary.

(file #16943)

Wolfgang Lux <wlux>
Sat 22 Nov 2008 06:55:06 PM UTC, comment #5: 

This is an issue for me as well.  SystemPreferences does not quit.  I'm currently using Slackware 12.1 and GNUstep SVN, but this has happened with every release since the previous stable release and Slackware 12.0.

It's only SystemPreferences that has this problem on my machine, I don't have a comprehensive install of GNUstep apps though.

Stef <stefanbidi>
Group Member
Sat 22 Nov 2008 03:16:10 PM UTC, comment #4: 

I'm trying to reproduce this on NetBSD.  It doesn't seem to be a problem on Linux or even Windows from what I've seen.

GC

Gregory John Casamento <gcasa>
Group administrator
Sat 22 Nov 2008 03:09:46 PM UTC, comment #3: 

I still cannot reproduce this with SystemPreferences. Looking at the code I noticed that this application does not use the normal main loop. Could this be a common property of all applications showing this behaviour? (Is there any appart from SystemPreferences?)

As long as there isn't further input from somebody getting this problem we wont be able to find a solution. I might even set the report on "works for me".

Fred Kiefer <FredKiefer>
Group Member
Sun 16 Nov 2008 01:52:52 PM UTC, comment #2: 

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


Fred Kiefer <FredKiefer>
Group Member
Mon 10 Nov 2008 12:39:40 PM UTC, comment #1: 

I can confirm this behavior with Preferences on GNU/kFreeBSD, GUI version 0.14.0.

Yavor Doganov <yavor>
Sat 08 Nov 2008 11:03:33 PM UTC, original submission:  

Entering into the bug system so that we can track this.   I observed this with SystemPreferences on Windows.

GC
-------

Hi Marko,

I heard from Riccardo that he is facing similar problems. Could you
please detail your environment and the applications that are failing to
stop? Are they document based, do you use an application delegate?
Does replyToApplicationShouldTerminate: get called? With what value as
parameter? And what happeneds then?

Fred

Marko Riedel wrote:

> I recently installed a GNUstep application on two new machines and
> ran into a problem that I hadn't encountered on the other machines
> where it is currently running successfully. I cannot quit the
> application by clicking on "Quit".
>
> The delegate method applicationShouldTerminate: gets called and
> returns YES but the application does not quit. This is a real
> nuisance. As a workaround, I invoke NSApplication's stop: method in
> applicationShouldTerminate:. That quits the applications and saves
> e.g. window positions to the defaults database, but is definitely not
> how it is supposed to be used.
>
> Any ideas what might be the problem here? This is with KDE 3.5 (I
> don't have a choice as to what windowmanager to use.)
>




_____________________________________________
Discuss-gnustep mailing list
-email is unavailable-
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Gregory John Casamento <gcasa>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #16943:  stacktrace added by wlux (7KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by qmathe (Posted a comment)
  • -email is unavailable- added by wlux (Updated the item)
  • -email is unavailable- added by stefanbidi (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by yavor (Posted a comment)
  • -email is unavailable- added by gcasa (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-12-16 rmottola Open/ClosedIn Test Closed
    2008-12-03 gcasa Assigned toNone gcasa
        Open/ClosedOpen In Test
    2008-12-03 gcasa StatusNone Fixed
    2008-11-29 wlux Attached File- Added stacktrace, #16943
    2008-11-08 gcasa CategoryNone Gui/AppKit
        Item GroupNone Bug

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code