Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux

[David Chisnall]

On 5 Dec 2017, at 20:01, Lobron, David <dlobron@akamai.com> wrote:
> 
> Hello GNUstep,
> 
> I'm trying to build a large Objective-C and Objective-C++ codebase on Linux 
> using clang, rather than gcc.  As part of this, I'm switching to libobjc2.
> 
> Almost all of my code is running correctly, but I'm finding that one unit 
> test is failing when the program receives a SIGABRT.  I ran the program under 
> Valgrind to check for memory corruption, and none was found.  This code all 
> runs correctly when built with gcc and using the gcc runtime, so the error 
> appears to be specific to clang and libobjc2 (although of course it might be 
> a bug in my code that the clang/libobjc2 combination is revealing).
> 
> The signal is delivered while the program is reading a fairly large file from 
> disk into a tree data structure.  I set a breakpoint on "abort", and the 
> stack trace pointed to NSRunLoop:
> 
> #0  __GI_abort () at abort.c:51
> #1  0x00007ffff4f6e521 in _Unwind_Resume (exc=0xa6de460) at 
> ../../../src/libgcc/unwind.inc:234
> #2  0x00007ffff5d32625 in -[NSRunLoop limitDateForMode:] (self=0xe13700, 
> _cmd=0x7ffff61b1e28 <.objc_selector_list+368>, mode=0x7ffff61b0e38 
> <.objc_str>)
>    at NSRunLoop.m:1119
> #3  0x00007ffff5d32cf6 in -[NSRunLoop runMode:beforeDate:] (self=0xe13700, 
> _cmd=0x7ffff61b1d68 <.objc_selector_list+176>, mode=0x7ffff61b0e38 
> <.objc_str>, 
>    date=0xf4d420) at NSRunLoop.m:1285
> #4  0x00007ffff5d32e01 in -[NSRunLoop runUntilDate:] (self=0xe13700, 
> _cmd=<optimized out>, date=0xf4d420) at NSRunLoop.m:1334
> #5  0x00007ffff6e9d2ec in -[AkamaiDaemon mainLoop] (self=0xb65610, 
> _cmd=<optimized out>) at AkamaiDaemon.m:1080
> 
> The line in frame 2 is a NS_ENDHANDLER call, inside of a method called  "- 
> (NSDate*) limitDateForMode: (NSString*)mode".  There's no call to abort in 
> that code.  I tried stepping line by line, but I did not see any exception 
> being thrown here.

_Unwind_Resume is the function that is used to resume stack unwinding after a 
cleanup.  It should only be called in Objective-C code at the end of an 
@finally block (with no corresponding catch block, just @try { … @throw … } 
@finally {}) or as the result of using __attribute__((cleanup)).

I believe that if you are targetting the gnustep runtime prior to 1.7 (or using 
a very old version of clang), it will be emitted by clang, but I don’t remember 
precisely what the EH ABI looked like before I fixed it (I think it called 
objc_exception_throw(), not _Unwind_Resume).

Please can you use a debug build of libobjc2 (that should prevent tail-call 
optimisation) and stick a breakpoint on _Unwind_Resume and see where it’s 
called from? 

David