discuss-gnustep
[Top][All Lists]
Advanced

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

Mysterious crash in NSRunLoop, using libobjc2 on Linux


From: Lobron, David
Subject: Mysterious crash in NSRunLoop, using libobjc2 on Linux
Date: Tue, 5 Dec 2017 20:01:16 +0000

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.

Has anyone seen this behavior before?  Should I be checking for stack 
corruption?  The error is reproducible, so I'm pretty sure it's not random 
corruption.

Thank you,

David


reply via email to

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