Re: GWorkspace ddbd dying when mdextractor connects

[Fred Kiefer]

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 <fredkiefer@gmx.de> wrote:
>
> > On 16.02.2013 20:11, Sebastian Reitenbach wrote:
> > > On Saturday, February 16, 2013 18:55 CET, Fred Kiefer <fredkiefer@gmx.de> 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