discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Emacs Anyone?


From: Richard Frith-Macdonald
Subject: Re: Emacs Anyone?
Date: Wed, 8 Mar 2017 10:29:34 +0000

> On 7 Mar 2017, at 17:30, Riccardo Mottola <riccardo.mottola@libero.it> wrote:
> 
> Hi,
> 
> Wolfgang Lux wrote:
>> Instead of speculating I would suggest getting definitive information by 
>> setting a breakpoint at the point where the missing autorelease pool is 
>> reported (line 368 in NSAutoreleasePool.m in the current svn version) and 
>> get a backtrace from gdb.:-)
> It is an issue that happens during building!
> 
> This is the trace I get:

Following through in the other direction to give you the sequence of events ...

This is trying to look up the method to be called ... presumably alloc

> #5  0xbb27c0d2 in objc_msg_lookup () from /usr/lib/libobjc.so.4

This suggests it failed to find the method, so is trying to forward it to a 
delegate

> #4  0xbb27a8d1 in __objc_get_forward_imp () from /usr/lib/libobjc.so.4
> #3  0xbb515add in gs_objc_msg_forward2 (
>    receiver=0xbb6c7f80 <_OBJC_Class_NSAutoreleasePool>,
>    sel=0x843a130 <_OBJC_SELECTOR_TABLE+1008>) at GSFFIInvocation.m:140

It found the method types information, and needs to create a method signature 
for forwardig

> #2  0xbb43051f in +[NSMethodSignature signatureWithObjCTypes:] (
>    self=0xbb6f64c0 <_OBJC_Class_NSMethodSignature>,
>    _cmd=0xbb7407a0 <_OBJC_SELECTOR_TABLE>,
>    t=0x843790c <_OBJC_METH_VAR_TYPE_11> "@8@0:4") at NSMethodSignature.m:559

It has created the method signature, and needs to autorelease it by calling 
[NSObject-autorelease]

> #1  0xbb4442c9 in -[NSObject autorelease] (self=0x8f57650,
>    _cmd=0xbb6f6440 <_OBJC_SELECTOR_TABLE+32>) at NSObject.m:1633

The -autorelease method tried to add the method signature to the current pool.

> #0  +[NSAutoreleasePool addObject:] (
>    self=0xbb6c7f80 <_OBJC_Class_NSAutoreleasePool>,
>    _cmd=0xbb6fd4d8 <_OBJC_SELECTOR_TABLE+120>, anObj=0x8f57650)
>    at NSAutoreleasePool.m:368


So all that makes perfect sense apart from the starting point; why did it fail 
to look up and invoke the alloc method of NSAutoreleasePool, and instead resort 
to the forwarding mechanism?
My guess is a runtime issue combined with class initialization order in the 
base library meansing that somehow the NSAutoreleasePool class was not properly 
initialised before the lookup of the alloc method.

I can't reproduce your behavior in a simplified testcase though (if I just have 
a main() method in a C file which calls a function in an ObjC file, which calls 
[[NSAutoreleasePool alloc] init], it just works as epected).

All I can suggest is trying something like [NSObject class] before the call to 
[[NSAutoreleasePool alloc] init] in them hope that it'll change class 
initialization order enough to not trigger any runtime issue.




reply via email to

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