discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GWorkspace hangs on first exit attempt. Remote objects problem?


From: Fred Kiefer
Subject: Re: GWorkspace hangs on first exit attempt. Remote objects problem?
Date: Sat, 09 Mar 2013 13:20:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

On 09.03.2013 10:48, Riccardo Mottola wrote:
Hi,

Richard Frith-Macdonald wrote:
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)?
I rebuitl base & gworkspace with debug=yes, this is what I get:
#0  -[NSException raise] (self=0x22ee5f8,
     _cmd=0x7ffff6e188e0 <_OBJC_SELECTOR_TABLE+384>) at NSException.m:956
#1  0x00007ffff69280ca in +[NSException raise:format:arguments:] (
     self=0x7ffff6e18500 <_OBJC_Class_NSException>,
     _cmd=0x7ffff6e188b0 <_OBJC_SELECTOR_TABLE+336>,
     name=0x7ffff6e4ba60 <_OBJC_INSTANCE_0>,
     format=0x7ffff6e03800 <_OBJC_INSTANCE_68>, argList=0x7fffffffd178)
     at NSException.m:849
#2  0x00007ffff6928013 in +[NSException raise:format:] (
     self=0x7ffff6e18500 <_OBJC_Class_NSException>,
     _cmd=0x7ffff6e05480 <_OBJC_SELECTOR_TABLE+1728>,
     name=0x7ffff6e4ba60 <_OBJC_INSTANCE_0>,
     format=0x7ffff6e03800 <_OBJC_INSTANCE_68>) at NSException.m:835
#3  0x00007ffff68ed9ab in -[NSConnection(Private) _getReplyRmc:] (
     self=0x126efd8, _cmd=0x7ffff6e053c0 <_OBJC_SELECTOR_TABLE+1536>,
sn=34)
     at NSConnection.m:3219
#4  0x00007ffff68e89ea in -[NSConnection(GNUstepExtensions)
forwardInvocation:forProxy:] (self=0x126efd8, _cmd=0x7ffff6e13f10
<_OBJC_SELECTOR_TABLE+592>,
     inv=0x1693178, object=0x145c068) at NSConnection.m:2086
#5  0x00007ffff6922b8d in -[NSDistantObject forwardInvocation:] (
     self=0x145c068, _cmd=0x7ffff6e9f5c0 <_OBJC_SELECTOR_TABLE+448>,
     anInvocation=0x1693178) at NSDistantObject.m:606
#6  0x00007ffff6a45458 in GSFFIInvocationCallback (cif=0x1711c60,
     retp=0x7fffffffd700, args=0x7fffffffd570, user=0x1711c28)
     at GSFFIInvocation.m:629
#7  0x00007ffff1bfed09 in ffi_closure_unix64_inner ()
    from /usr/lib64/libffi.so.6
#8  0x00007ffff1bff054 in ffi_closure_unix64 () from /usr/lib64/libffi.so.6
#9  0x000000000040e5d4 in -[GWorkspace applicationShouldTerminate:] (
     self=0xd30ac8, _cmd=0x7ffff75507a0 <_OBJC_SELECTOR_TABLE+5984>,
     app=0xd4ff28) at GWorkspace.m:635
#10 0x00007ffff70c5f42 in -[NSApplication terminate:] (self=0xd4ff28,
     _cmd=<optimized out>, sender=<optimized out>) at NSApplication.m:3462

(gdb) frame 9
#9  0x000000000040e5d4 in -[GWorkspace applicationShouldTerminate:] (
     self=0xd30ac8, _cmd=0x7ffff75507a0 <_OBJC_SELECTOR_TABLE+5984>,
     app=0xd4ff28) at GWorkspace.m:635
635                 [fswatcher unregisterClient: (id
<FSWClientProtocol>)self];
(gdb) p _cmd
$1 = (const struct objc_selector *) 0x7ffff75507a0
<_OBJC_SELECTOR_TABLE+5984>

I don't know how to print the contents of _cmd, like Sebastian did.

Hoever, for frame 6, I get:
#6  0x00007ffff6a45458 in GSFFIInvocationCallback (cif=0x1711c60,
     retp=0x7fffffffd700, args=0x7fffffffd570, user=0x1711c28)
     at GSFFIInvocation.m:629
629       [obj forwardInvocation: invocation];
(gdb) p invocation
$4 = (struct GSFFIInvocation *) 0x1693178
(gdb) p *invocation
$5 = {{{isa = 0x7ffff6e9f380 <_OBJC_Class_GSFFIInvocation>}, _sig =
0x1693138,
     _cframe = 0x1711c60, _retval = 0x0, _target = 0x145c068,
     _selector = 0x6d7440 <_OBJC_SELECTOR_TABLE+1792>, _numArgs = 3,
     _info = 0x165b960, _argsRetained = 0 '\000', _targetRetained = 0
'\000',
     _validReturn = 0 '\000', _sendToSuper = 0 '\000', _retptr = 0x0,
     _internal = 0x0}, _retbuf = '\000' <repeats 31 times>, _frame =
0x1711c28}
(gdb) p invocation->_sig
$6 = (struct NSMethodSignature *) 0x1693138

here I checked:
(gdb) p [invocation->_sig isOneway]
$7 = 1 '\001'

so it appears that the information about oneway is properly passed, right?
(gdb) p invocation->_sig->_methodTypes
$9 = 0x17a9c30 "Vv24@0:8@16"

Is this enough? In case not you need to tell me which part to inspect.


I think the interesting stuff happens in frame 4. There we end up in the needsResponse == YES branch, which seems wrong for a one way method call. You should have a look at the block from line 2016 to 2039 and find out why needsResponse gets set to YES. Most likely the method type gets compute wrongly. We seem to get these strange results sometimes from libobjc2.



reply via email to

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