> 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 simp
> On 6 Dec 2017, at 16:53, Lobron, David 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
>>>
On 6 Dec 2017, at 13:46, Andreas Fink wrote:
>
> Hello folks,
>
> I have a heavily multithreaded application which produces two different
> crashes in libobjc2 code now.
> I believe I have hit a race condition.
>
> Here is the firs thread at SIGABRT:
>
>
> * frame #0: 0x76f701be
> l
>> 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 tha
Hello folks,
I have a heavily multithreaded application which produces two different crashes
in libobjc2 code now.
I believe I have hit a race condition.
Here is the firs thread at SIGABRT:
* frame #0: 0x76f701be
libobjc.so.4.6`objc_storeWeak(addr=0x7fff7be0d628, obj=0x00d
