[Top][All Lists]

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

Re: Emacs Anyone?

From: Steven Nunez
Subject: Re: Emacs Anyone?
Date: Sat, 25 Mar 2017 08:02:39 +0000 (UTC)

Hi Guys,

Just wondering if this emacs bug ever got fixed? I'm keen to dump the Gnome version that comes installed with FreeBSD and make everything I use 'native' GNUStep.

Anything I can do to help, short of coding (I would if I could), but ObjC isn't something I know.

    - Steve

On Monday, March 13, 2017 5:31 PM, Wolfgang Lux <wolfgang.lux@gmail.com> wrote:

> 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. :-(


Discuss-gnustep mailing list

reply via email to

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