On 26 Jan 2019, at 11:57, Andreas Fink <[email protected]> wrote: > > * thread #1, name = 'basictypes', stop reason = signal SIGSEGV: invalid > address (fault address: 0x7fffff7feffc) > * frame #0: 0x00007ffff6a22d4e libc.so.6`_IO_vfprintf + 30 > frame #1: 0x00007ffff6a4be89 libc.so.6`vsnprintf + 121 > frame #2: 0x00007ffff6a2b2c2 libc.so.6`snprintf + 130 > frame #3: 0x00007ffff79060f4 libgnustep-base.so.1.26`-[NSMethodSignature > _initWithObjCTypes:](self=0x000000000150d8f8, _cmd=<unavailable>, > t=<unavailable>) at NSMethodSignature.m:539:4 > frame #4: 0x00007ffff7906241 libgnustep-base.so.1.26`+[NSMethodSignature > signatureWithObjCTypes:](self=<unavailable>, _cmd=<unavailable>, > t=<unavailable>) at NSMethodSignature.m:559:10 > frame #5: 0x00007ffff79a7d4a > libgnustep-base.so.1.26`gs_objc_msg_forward2(receiver=0x00007ffff7d864f8, > sel="\xffffff90\n") at GSFFIInvocation.m:140:13 > frame #6: 0x00007ffff72ae2c1 libobjc.so.4.6`slowMsgLookup at > sendmsg2.c:149:28
I’ve seen this before. What linker are you using? When I saw this, it was because of a bug in old BFD ld's handling of ld -r when linking the Base Additions library, which caused it to delete the category that contained the lockAt: method. This then caused infinite recursion in NSObject’s initialisation. Both lld and gold appear to work fine (though lld doesn’t work for SOPE, for reasons I’ve not yet been able to track down). David _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
