[bug #24785] Application not quitting properly on some platforms.
Update of bug #24785 (project gnustep): Open/Closed: In Test = Closed ___ Follow-up 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Messaggio inviato con/da Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #21, bug #24785 (project gnustep): 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 ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #14, bug #24785 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #15, bug #24785 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #16, bug #24785 (project gnustep): 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). ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #17, bug #24785 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #18, bug #24785 (project gnustep): 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 ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #19, bug #24785 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #20, bug #24785 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #12, bug #24785 (project gnustep): 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? ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #13, bug #24785 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Update of bug #24785 (project gnustep): Status:None = Fixed Assigned to:None = gcasa Open/Closed:Open = In Test ___ Follow-up 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 ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #11, bug #24785 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #8, bug #24785 (project gnustep): Fred, Looks like you get the same problem I had last week, Richard fixed it, see bug report #24939 Quentin. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message posté via/par Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #9, bug #24785 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #6, bug #24785 (project gnustep): 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) ___ Additional Item Attachment: File name: stacktrace Size:6 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #7, bug #24785 (project gnustep): 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)] 0xe430 in __kernel_vsyscall () (gdb) bt #0 0xe430 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 ' ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #3, bug #24785 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #4, bug #24785 (project gnustep): 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 ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #5, bug #24785 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
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 [EMAIL PROTECTED], Marko Riedel [EMAIL PROTECTED] 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/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
Follow-up Comment #1, bug #24785 (project gnustep): I can confirm this behavior with Preferences on GNU/kFreeBSD, GUI version 0.14.0. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #24785] Application not quitting properly on some platforms.
URL: http://savannah.gnu.org/bugs/?24785 Summary: Application not quitting properly on some platforms. Project: GNUstep Submitted by: gcasa Submitted on: Sat 08 Nov 2008 06:03:33 PM EST Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: 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 PROTECTED] http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Reply to this item at: http://savannah.gnu.org/bugs/?24785 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
