[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux
From: |
Lobron, David |
Subject: |
Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux |
Date: |
Wed, 6 Dec 2017 16:53:09 +0000 |
>> 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?
Thank you,
David
Possibly problematic compile lines that target gnustep-1.7:
/home/dlobron/build/clangport/akamai/llvm/llvm-5.0.0.install/bin/clang
-DGC_DEBUG -DGNUSTEP -DNO_LEGACY -DTYPE_DEPENDENT_DISPATCH -D_BSD_SOURCE=1
-D_XOPEN_SOURCE=700 -D__BSD_VISIBLE=1 -D__OBJC_RUNTIME_INTERNAL__=1
-Dobjc_EXPORTS -std=gnu99 -fexceptions -g -O0 -fno-inline -g -fPIC
-Wno-deprecated-objc-isa-usage -Wno-objc-root-class -fobjc-runtime=gnustep-1.7
-o CMakeFiles/objc.dir/Protocol2.m.o -c
/home/dlobron/build/clangport/akamai/libobjc2/libobjc2-1.8.1/Protocol2.m
[ 82%] Building ASM object CMakeFiles/objc.dir/objc_msgSend.S.o
/usr/bin/clang -DGC_DEBUG -DGNUSTEP -DNO_LEGACY -DTYPE_DEPENDENT_DISPATCH
-D_BSD_SOURCE=1 -D_XOPEN_SOURCE=700 -D__BSD_VISIBLE=1
-D__OBJC_RUNTIME_INTERNAL__=1 -Dobjc_EXPORTS -c -o
CMakeFiles/objc.dir/objc_msgSend.S.o -c
/home/dlobron/build/clangport/akamai/libobjc2/libobjc2-1.8.1/objc_msgSend.S
[ 85%] Building C object CMakeFiles/objc.dir/arc.m.o
/home/dlobron/build/clangport/akamai/llvm/llvm-5.0.0.install/bin/clang
-DGC_DEBUG -DGNUSTEP -DNO_LEGACY -DTYPE_DEPENDENT_DISPATCH -D_BSD_SOURCE=1
-D_XOPEN_SOURCE=700 -D__BSD_VISIBLE=1 -D__OBJC_RUNTIME_INTERNAL__=1
-Dobjc_EXPORTS -std=gnu99 -fexceptions -g -O0 -fno-inline -g -fPIC
-Wno-deprecated-objc-isa-usage -Wno-objc-root-class -fobjc-runtime=gnustep-1.7
-o CMakeFiles/objc.dir/arc.m.o -c
/home/dlobron/build/clangport/akamai/libobjc2/libobjc2-1.8.1/arc.m
[ 88%] Building C object CMakeFiles/objc.dir/associate.m.o
/home/dlobron/build/clangport/akamai/llvm/llvm-5.0.0.install/bin/clang
-DGC_DEBUG -DGNUSTEP -DNO_LEGACY -DTYPE_DEPENDENT_DISPATCH -D_BSD_SOURCE=1
-D_XOPEN_SOURCE=700 -D__BSD_VISIBLE=1 -D__OBJC_RUNTIME_INTERNAL__=1
-Dobjc_EXPORTS -std=gnu99 -fexceptions -g -O0 -fno-inline -g -fPIC
-Wno-deprecated-objc-isa-usage -Wno-objc-root-class -fobjc-runtime=gnustep-1.7
-o CMakeFiles/objc.dir/associate.m.o -c
/home/dlobron/build/clangport/akamai/libobjc2/libobjc2-1.8.1/associate.m
[ 91%] Building C object CMakeFiles/objc.dir/blocks_runtime.m.o
/home/dlobron/build/clangport/akamai/llvm/llvm-5.0.0.install/bin/clang
-DGC_DEBUG -DGNUSTEP -DNO_LEGACY -DTYPE_DEPENDENT_DISPATCH -D_BSD_SOURCE=1
-D_XOPEN_SOURCE=700 -D__BSD_VISIBLE=1 -D__OBJC_RUNTIME_INTERNAL__=1
-Dobjc_EXPORTS -std=gnu99 -fexceptions -g -O0 -fno-inline -g -fPIC
-Wno-deprecated-objc-isa-usage -Wno-objc-root-class -fobjc-runtime=gnustep-1.7
-o CMakeFiles/objc.dir/blocks_runtime.m.o -c
/home/dlobron/build/clangport/akamai/libobjc2/libobjc2-1.8.1/blocks_runtime.m
[ 94%] Building C object CMakeFiles/objc.dir/properties.m.o
/home/dlobron/build/clangport/akamai/llvm/llvm-5.0.0.install/bin/clang
-DGC_DEBUG -DGNUSTEP -DNO_LEGACY -DTYPE_DEPENDENT_DISPATCH -D_BSD_SOURCE=1
-D_XOPEN_SOURCE=700 -D__BSD_VISIBLE=1 -D__OBJC_RUNTIME_INTERNAL__=1
-Dobjc_EXPORTS -std=gnu99 -fexceptions -g -O0 -fno-inline -g -fPIC
-Wno-deprecated-objc-isa-usage -Wno-objc-root-class -fobjc-runtime=gnustep-1.7
-o CMakeFiles/objc.dir/properties.m.o -c
/home/dlobron/build/clangport/akamai/libobjc2/libobjc2-1.8.1/properties.m
[ 97%] Building C object CMakeFiles/objc.dir/gc_none.c.o
/home/dlobron/build/clangport/akamai/llvm/llvm-5.0.0.install/bin/clang
-DGC_DEBUG -DGNUSTEP -DNO_LEGACY -DTYPE_DEPENDENT_DISPATCH -D_BSD_SOURCE=1
-D_XOPEN_SOURCE=700 -D__BSD_VISIBLE=1 -D__OBJC_RUNTIME_INTERNAL__=1
-Dobjc_EXPORTS -std=gnu99 -fexceptions -g -O0 -fno-inline -g -fPIC
-Wno-deprecated-objc-isa-usage -Wno-objc-root-class -fobjc-runtime=gnustep-1.7
-o CMakeFiles/objc.dir/gc_none.c.o -c
/home/dlobron/build/clangport/akamai/libobjc2/libobjc2-1.8.1/gc_none.c
[100%] Linking C shared library libobjc.so
- Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/05
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/06
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux,
Lobron, David <=
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/06
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/06
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/07
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/07
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/07
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/07
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/07
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/11
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, David Chisnall, 2017/12/11
- Re: Mysterious crash in NSRunLoop, using libobjc2 on Linux, Lobron, David, 2017/12/11