discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GWorkspace ddbd dying when mdextractor connects


From: Fred Kiefer
Subject: Re: GWorkspace ddbd dying when mdextractor connects
Date: Sat, 16 Feb 2013 22:47:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2

You only replied to me. I am sending this back to the mailing list. BTW, the GNUstep dev mailing list would have been a better place to start this thread.

On 16.02.2013 22:28, Sebastian Reitenbach wrote:

On Saturday, February 16, 2013 21:11 CET, Fred Kiefer <address@hidden> wrote:

On 16.02.2013 20:11, Sebastian Reitenbach wrote:

On Saturday, February 16, 2013 18:55 CET, Fred Kiefer <address@hidden> wrote:

On 16.02.2013 15:21, Sebastian Reitenbach wrote:
Hi,

having ddbd from GWorkspace running, then, when starting mdextractor, the 
latter tries to connect
to ddbd, but will die because of:
/usr/local/bin/mdextractor: Uncaught exception NSInvalidReceivePortException, 
reason: invalidated while awaiting reply

reason for this exception is, ddbd is dying.
With gdb connected to a running ddbd, I get this backtrace when it segfaults:

Program received signal SIGSEGV, Segmentation fault.
0x0ef02527 in objc_msgSend () from /usr/local/lib/libobjc2.so.1.0
(gdb) bt
#0  0x0ef02527 in objc_msgSend () from /usr/local/lib/libobjc2.so.1.0
#1  0x0307aaf3 in -[GSFFIInvocation invokeWithTarget:] (self=0x8bcec384, 
_cmd=0x22db3a98 <.objc_selector_list+168>, anObject=0x87a82cc4)
       at GSFFIInvocation.m:483
#2  0x02effe02 in -[NSInvocation invoke] (self=0x8bcec384, _cmd=0x22da4700 
<.objc_selector_list+1120>) at NSInvocation.m:658
#3  0x02e8287d in -[NSConnection(Private) _service_forwardForProxy:] 
(self=0x82439fd4, _cmd=0x22da43c8 <.objc_selector_list+296>,
       aRmc=0x8bcec704) at NSConnection.m:2706
#4  0x02e800d6 in -[NSConnection(Private) handlePortMessage:] (self=0x8206da04, 
_cmd=0x22dea1b0 <.objc_selector_list+384>,
       msg=0x87a82704) at NSConnection.m:2343
#5  0x03064c25 in -[NSMessagePort handlePortMessage:] (self=0x83ccafa4, 
_cmd=0x22dea1b0 <.objc_selector_list+384>, m=0x87a82704)
       at NSMessagePort.m:1586
#6  0x030601f4 in -[GSMessageHandle receivedEvent:type:extra:forMode:] 
(self=0x8878f604, _cmd=0x22dea268 <.objc_selector_list+568>,
       data=0x83ccafa4, type=ET_RPORT, extra=0x3, mode=0x22dcc3b0 <.objc_str>) 
at NSMessagePort.m:869
#7  0x0306587f in -[NSMessagePort receivedEvent:type:extra:forMode:] 
(self=0x83ccafa4, _cmd=0x22e07c50 <.objc_selector_list+96>,
       data=0x83ccafa4, type=ET_RPORT, extra=0x3, mode=0x22dcc3b0 <.objc_str>) 
at NSMessagePort.m:1715
#8  0x030d6d77 in -[GSRunLoopCtxt pollUntil:within:] (self=0x82085704, 
_cmd=0x22dcc600 <.objc_selector_list>, milliseconds=29928,
       contexts=0x8207bd44) at GSRunLoopCtxt.m:639
#9  0x02fa6605 in -[NSRunLoop acceptInputForMode:beforeDate:] (self=0x8207bec4, 
_cmd=0x22dcc668 <.objc_selector_list+104>,
       mode=0x22dcc3b0 <.objc_str>, limit_date=0x87189db4) at NSRunLoop.m:1206
#10 0x02fa6bb4 in -[NSRunLoop runMode:beforeDate:] (self=0x8207bec4, _cmd=0x22dcc678 
<.objc_selector_list+120>,
       mode=0x22dcc3b0 <.objc_str>, date=0x8206d104) at NSRunLoop.m:1274
#11 0x02fa6e5d in -[NSRunLoop runUntilDate:] (self=0x8207bec4, _cmd=0x22dcc748 
<.objc_selector_list+328>, date=0x8206d104)
       at NSRunLoop.m:1305
#12 0x02fa6c37 in -[NSRunLoop run] (self=0x8207bec4, _cmd=0x3c006dc0 
<.objc_selector_list+464>) at NSRunLoop.m:1288
#13 0x1c008978 in gnustep_base_user_main (argc=2, argv=0xcfbf61d4) at ddbd.m:553
#14 0x02f85957 in main (argc=2, argv=0xcfbf61d4, env=0xcfbf61e0) at 
NSProcessInfo.m:984
#15 0x1c005599 in ___start ()
#16 0x1c00550a in _start ()
(gdb) frame 4
#4  0x02e800d6 in -[NSConnection(Private) handlePortMessage:] (self=0x8206da04, 
_cmd=0x22dea1b0 <.objc_selector_list+384>,
       msg=0x87a82704) at NSConnection.m:2343
2343                [conn _service_forwardForProxy: rmc];       // Catches 
exceptions
(gdb) print 1
$1 = 1
(gdb) frame 1
#1  0x0307aaf3 in -[GSFFIInvocation invokeWithTarget:] (self=0x8bcec384, 
_cmd=0x22db3a98 <.objc_selector_list+168>, anObject=0x87a82cc4)
       at GSFFIInvocation.m:483
483       RETAIN_RETURN_VALUE;
(gdb) list
478       if (*type != _C_VOID)
479         {
480           cifframe_decode_arg(type, _retval);
481         }
482
483       RETAIN_RETURN_VALUE;
484       _validReturn = YES;
485     }
486
487     @end
(gdb) frame 0
#0  0x0ef02527 in objc_msgSend () from /usr/local/lib/libobjc2.so.1.0
(gdb) list
488
489     /*
490      * Return YES if the selector contains protocol qualifiers.
491      */
492     static BOOL
493     gs_protocol_selector(const char *types)
494     {
495       if (types == 0)
496         {
497           return NO;
(gdb) print types

Program received signal SIGSEGV, Segmentation fault.


since its dying deep within gnustep-base, I'm a bit unsure whether this is a 
problem of the tools from
GWorkspace, or a more general problem in -base.

I'm on i386, OpenBSD 5.3-beta, with -base,make,gui,back,gworkspace from SVN.


The first thing you should try to do is print out the invocation. (That
is in frame 1 do a "po self") If that works please report back the
output. This should give a hint at which method gets invoked with a
wrong signature. Most likely this has to do with all the 64bit changes
going on at the moment.

(gdb) print self
$1 = (struct GSFFIInvocation *) 0x89d5ad04
(gdb) print *self
$2 = {<> = {<> = {isa = 0x2a975770 <_OBJC_CLASS_GSFFIInvocation>}, _sig = 0x2a975770 
<_OBJC_CLASS_GSFFIInvocation>,
      _cframe = 0x2a975770 <_OBJC_CLASS_GSFFIInvocation>, _retval = 0x2a975770 
<_OBJC_CLASS_GSFFIInvocation>,
      _target = 0x2a975770 <_OBJC_CLASS_GSFFIInvocation>, _selector = 0x2a975770 
<_OBJC_CLASS_GSFFIInvocation>, _numArgs = 714561392,
      _info = 0x2a975770 <_OBJC_CLASS_GSFFIInvocation>, _argsRetained = 112 
'p', _targetRetained = 112 'p', _validReturn = 112 'p',
      _sendToSuper = 112 'p', _retptr = 0x2a975770 
<_OBJC_CLASS_GSFFIInvocation>,
      _internal = 0x2a975770 <_OBJC_CLASS_GSFFIInvocation>},
    _retbuf = 
"pW\227*\004­\e\201\200¬Õ\2110­Õ\211D¼½\201øNó\200\003\000\000\000\000¶W\177",
    _frame = 0x2a975770 <_OBJC_CLASS_GSFFIInvocation>}

The results you get here are nonsensical. The best you may do now is to
try to add an NSLog() statement in NSConnection.m at line 2608 and print
out the invocation before the arguments get set. We are mostly
interested in the selector, the target will be an NSProxy object.

This is the output, with the NSLog added there:

2013-02-16 22:24:33.610 ddbd[17606] the invocation: <GSFFIInvocation 0x804e9a04 
selector: postNotification: target: NSNotificationCenter>
2013-02-16 22:24:43.050 ddbd[17606] the invocation: <GSFFIInvocation 0x804e9c84 
selector: userMetadataForPath: target: DDBd>
2013-02-16 22:24:43.051 ddbd[17606] the invocation: <GSFFIInvocation 0x804e9c84 
selector: userMetadataForPath: target: DDBd>

Program received signal SIGSEGV, Segmentation fault.
0x07bbe527 in objc_msgSend () from /usr/local/lib/libobjc2.so.1.0
...


I still think that we are dealing with a type mismatch here, but I could

That something in ddbd or GWorkspace was changed to be 64Bit, but
some part is missing which is now causing problem?

be wrong. Perhaps the target object is already released and things go
wrong because of that.

Looks like I was wrong. The signature of userMetadataForPath: hasn't changed during the 64bit changes, so this is completely unrelated. My new guess is that the problem is in the ddbd code or in the NSProxy handling. You could investigate the first possibility by adding a lot of debug logs into ddbd.m. For the second option Richard is the one to talk to.

There is one strange thing I see in the code in ddbd.m. You don't retain the connection, still you release it in the -dealloc method. Most likely you should retain it in the -init method. Forgetting that, together with this code in main():

    CREATE_AUTORELEASE_POOL (pool);
          DDBd *ddbd = [[DDBd alloc] init];
    RELEASE (pool);

may result in the connection going away too soon.

Fred



reply via email to

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