On 8 Mar 2013, at 01:09, Riccardo Mottola wrote:

> Hi,
> 
> some further information
> 
> 1) unregisterClient is (oneway void). So it is asynchronous, no need to wait 
> for any value returned (Sebastian suggested doing this to me, but is already 
> correct)
> 2) if I wrap [fswatcher unregisterClient] in an exception handler, on the 
> machines which caouse problems I do get an exception.
> 
> 2013-03-08 01:06:25.990 GWorkspace[7503] [GWorkspace 
> shouldTerminateApplication] unregister fswatcher: <NSException: 0x318ac38> 
> NAME:NSInvalidReceivePortException REASON:invalidated while awaiting reply 
> INFO:(null)
> 
> Doesn't it look like exit() kills fswatcher but something still needs to be 
> sent? The stacktrace is:
> 
> #0  -[NSException raise] (self=0x232efb8,
>    _cmd=0x7ffff6e2f9e0 <_OBJC_SELECTOR_TABLE+384>) at NSException.m:955
> #1  0x00007ffff696a6f1 in +[NSException raise:format:] (
>    self=0x7ffff6e2fb40 <_OBJC_Class_NSException>, _cmd=<optimized out>,
>    name=0x7ffff6e63120 <_OBJC_INSTANCE_0>,
>    format=0x7ffff6e1b200 <_OBJC_INSTANCE_68>) at NSException.m:835
> #2  0x00007ffff69383e3 in -[NSConnection(Private) _getReplyRmc:] (
>    self=0x124a7d8, _cmd=0x7ffff6e1cdc0 <_OBJC_SELECTOR_TABLE+1536>, sn=26)
>    at NSConnection.m:3219
> #3  0x00007ffff6933422 in -[NSConnection(GNUstepExtensions) 
> forwardInvocation:forProxy:] (self=0x124a7d8, _cmd=0x7ffff6e2ad10 
> <_OBJC_SELECTOR_TABLE+592>,
>    inv=0x22bd328, object=0x12de0f8) at NSConnection.m:2086
> #4  0x00007ffff6a7472b in GSFFIInvocationCallback (cif=0x232eee0,
>    retp=0x7fffffffd7a0, args=<optimized out>, user=0x2366718)
>    at GSFFIInvocation.m:629
> #5  0x00007ffff1c4ad09 in ffi_closure_unix64_inner ()
>   from /usr/lib64/libffi.so.6
> #6  0x00007ffff1c4b054 in ffi_closure_unix64 () from /usr/lib64/libffi.so.6
> #7  0x00000000004137ad in -[GWorkspace applicationShouldTerminate:] (
>    self=0xd0ca48, _cmd=<optimized out>, app=<optimized out>)
>    at GWorkspace.m:635
> #8  0x00007ffff70daf02 in -[NSApplication terminate:] (self=0xd2be98,
>    _cmd=<optimized out>, sender=<optimized out>) at NSApplication.m:3462
> 
> 
> I see _getReplyRmc:  but there is going to be none, the app is dead and it is 
> oneway void.
> 
> Does this sound plausible?

If it's a oneway void cal, it shouldn't be waiting for a reply.
You could try going back up the stack a bit and examining the invocation, to 
see what selector is actually being used and what the type information for the 
selector is (does it think it's oneway)?


_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Reply via email to