Re: Emacs Anyone?

[Wolfgang Lux]

> Am 07.03.2017 um 18:30 schrieb Riccardo Mottola <riccardo.mottola@libero.it>:
> 
> 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:
> (gdb) bt
> #0  +[NSAutoreleasePool addObject:] (
>    self=0xbb6c7f80 <_OBJC_Class_NSAutoreleasePool>,
>    _cmd=0xbb6fd4d8 <_OBJC_SELECTOR_TABLE+120>, anObj=0x8f57650)
>    at NSAutoreleasePool.m:368
> #1  0xbb4442c9 in -[NSObject autorelease] (self=0x8f57650,
>    _cmd=0xbb6f6440 <_OBJC_SELECTOR_TABLE+32>) at NSObject.m:1633
> #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
> #3  0xbb515add in gs_objc_msg_forward2 (
>    receiver=0xbb6c7f80 <_OBJC_Class_NSAutoreleasePool>,
>    sel=0x843a130 <_OBJC_SELECTOR_TABLE+1008>) at GSFFIInvocation.m:140
> #4  0xbb27a8d1 in __objc_get_forward_imp () from /usr/lib/libobjc.so.4
> #5  0xbb27c0d2 in objc_msg_lookup () from /usr/lib/libobjc.so.4
> #6  0x081e3546 in ns_alloc_autorelease_pool () at nsterm.m:642
> #7  0x08218a20 in main (argc=<optimized out>, argv=0xbfbfea5c) at emacs.c:1213
> 
> a bit of context shows... that it is the allocation of the ARP itself!
> 
> 641     {
> 642       return [[NSAutoreleasePool alloc] init];
> 643     }
> 644

Richard Frith-Macdonald wrote:
> 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?

I have been able to reproduce this issue on NetBSD. The problem is that the 
alloc method is called with an unregistered selector. Setting the breakpoint as 
above and going up to the gs_objc_msg_forward2 frame, gdb shows this:
(gdb) print sel
$3 = (SEL) 0x840d530
(gdb) print *sel
$4 = {sel_id = 0x840b189, sel_types = 0x64098ff "@8@0:4"}
The sel_id field looks odd, it should be a two-level index, with one index in 
the lower two 20 bits and another one in the next 20 bits. However, sel_id here 
still points to the name of the selector:
(gdb) print (char *)sel->sel_id
$5 = 0x840b189 "alloc"
Normally, selectors are registered by calling an implicit function 
__objc_gnu_init generated by the compiler for each Objective-C source file. 
This is done by adding its address to the .ctors section of the ELF object 
file, which is supposed to be executed before the main program (like 
constructors for static objects in C++). This section is present unchanged in 
both the intermediate temacs executable (built in the src directory, where 
__objc_gnu_init gets called and everything works fine) and the final emacs 
executable after the dump and restore process. So it looks like they've changed 
the startup code for the final executable to not execute the functions recorded 
.ctors section. :-(

Wolfgang