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
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
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
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
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
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
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
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
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
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
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
Update of bug #24785 (project gnustep):
Status:None = Fixed
Assigned to:None = gcasa
Open/Closed:Open = In Test
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
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
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
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
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:
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
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:
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
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
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
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
23 matches
Mail list logo
