Re: assertion when using clang + libobjc2

[Riccardo Mottola]

Hi,

David Chisnall wrote:
> Thank you for the report.  Most of the tests don’t build with the GCC ABI, so 
> that code path is not as well tested as the two newer ABIs - thank you for 
> testing it, and please do file bugs if you hit any more issues.  I believe this 
> is now fixed in git.

indeed, we are a little further. gnustep-base tools do run now!
However, if I launch and GUI application, it will crash, with this 
stacktrace:

Program received signal SIGSEGV, Segmentation fault.
__strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:33
33      ../sysdeps/i386/i686/multiarch/../strcmp.S: No such file or 
directory.
(gdb) bt
#0  __strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:33
#1  0xb72038c0 in string_compare ()
   from /System/Library/Libraries/libobjc.so.4.6
#2  0xb72037bc in sel_isEqual () from 
/System/Library/Libraries/libobjc.so.4.6
#3  0xb71fe08d in get_method_description ()
   from /System/Library/Libraries/libobjc.so.4.6
#4  0xb71fdf8f in protocol_getMethodDescription ()
   from /System/Library/Libraries/libobjc.so.4.6
#5  0xb7517f60 in GSProtocolGetMethodDescriptionRecursive (
    aProtocol=<optimized out>, aSel=<optimized out>, isRequired=76 'L',
    isInstance=248 '\370') at GSObjCRuntime.m:827
#6  0xb73fd484 in -[NSDistantObject methodSignatureForSelector:] (
    self=0x868b14c, _cmd=<optimized out>,
    aSelector=0xb77c1ff8 <.objc_selector_list+320>) at 
NSDistantObject.m:727
#7  0xb75159e7 in GSFFIInvocationCallback (cif=<optimized out>,
    retp=<optimized out>, args=<optimized out>, user=<optimized out>)
    at GSFFIInvocation.m:538
#8  0xb4bb9a75 in ?? () from /usr/lib/libffi.so.6
#9  0xb4bb9e26 in ?? () from /usr/lib/libffi.so.6
#10 0xb7400ab0 in -[NSDistributedNotificationCenter(Private) _connect] (
    self=<optimized out>, _cmd=<optimized out>)
    at NSDistributedNotificationCenter.m:781
#11 0xb73ff743 in -[NSDistributedNotificationCenter 
addObserver:selector:name:ob

I thus did run base's tests... here the results:

   6924 Passed tests
     30 Dashed hopes
      9 Failed files
      8 Skipped sets
      5 Failed tests


that's not that good on a standard linux x86 system, but not a disaster 
either.

Failed test:         general.m:37 ... -classNamed returns the correct class
Failed test:         general.m:49 ... -executablePath returns an 
executable path (gnustep bundle)
Failed test:       general.m:61 ... -principalClass returns TestClass 
for +bundleForClass:[TestClass class]
Failed file:     test00.m aborted without running all tests!
Failed file:     test02.m aborted without running all tests!
Failed file:     basic.m aborted without running all tests!
Failed file:     test01.m aborted without running all tests!
Failed file:     test02.m aborted without running all tests!
Failed file:     test03.m aborted without running all tests!
Failed file:     test04.m aborted without running all tests!
Failed file:     test05.m aborted without running all tests!
Failed file:     test06.m aborted without running all tests!
Failed test:     test01.m:44 ... Got the correct data from a 200 - 
status load
Failed test:     test01.m:58 ... 404 - status: Handle load not loaded 
(resource not found)


only the general.m are probably worrysome, I suppose, they refer to 
bundles though and no crash

Riccardo