> On 6 Dec 2017, at 16:53, Lobron, David <[email protected]> wrote: > > >>> 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). > > I'm targeting the gnustep-1.8 in my gnustep-make flags, and all of my own > code is being built with -fobjc-runtime=gnustep-1.8. However, I now see that > a few .o files in libobjc2 are being compiled with -fobjc-runtime=gnustep-1.7 > rather than 1.8. Could that be the problem? I've copied those compile > commands at the end of this message. I'm using clang-6.0.0, from llvm-5.0.0, > which should be the latest stable version. > >> 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? > > Done. The last few lines of the backtrace look like this: > > #0 _Unwind_Resume (exc=0xa6c82e0) at ../../../src/libgcc/unwind.inc:224 > #1 0x00007ffff6f2851d in -[RadixTree > initWithFileDescriptor:symbolParserFunction:context:] (self=<optimized out>, > _cmd=<optimized out>, fd=<optimized out>, > parser=0x4d2430 <parsePingTreeSymbol(NSString*, void*)>, > context=0x2dee800) at RadixTree.mm:863 > #2 0x00000000004d23e7 in -[PingTreeParser pingTreeWithFile:] > (self=0x7fffffffb998, _cmd=<optimized out>, path=0x0) at PingState.mm:305 > > RadixTree.mm is a file from my own codebase. Line 863 of that code is an > NS_ENDHANDLER block. The lines leading up to, and including, line 863 look > like this: > > readTree(self, _root, indexMap); > gzclose(_gzFile); > _gzFile = 0; > } NS_HANDLER { > [self release]; > [localException retain]; > [pool release]; > [[localException autorelease] raise]; > } NS_ENDHANDLER > > I can send a longer excerpt if it would be helpful. The code itself has been > around a long time, and has worked under gcc/gnu runtime for a long time. > Also, it's running fine with clang/libobjc2 on a number of similar inputs in > other unit tests- it's just this one particular test that triggers the > SIGABORT. > > Is there another debugging step I might take here, or does this output > suggest the source of the problem?
I’m not sure why you’re seeing a call to _Unwind_Resume from NS_ENDHANDLER. It looks as if you have some cleanup code in that block that is being run when you throw the exception from the -raise method. Actually, this entire block looks fragile and redundant - what happens if you simply delete the entire EH block here? Exception objects are retained / released by the runtime, so don’t need special handling to propagate past autoreleasepool boundaries. David _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
