What `partial apply for closure #1 in closure #1 in Double.init<A>(_:)` crash is about?

Question

Created Sep ’23

Replies 2

Boosts 0

Views 2.1k

Participants 3

I give up: I have been investigating this crash that is impacting hugely my product, without finding the cause. Crashlitics shows me that this bug started on a certain date, after I released a new version, but I can't match anything with this crash.

Do you have any idea of what this could be caused from? Can you provide an example of code that could be generating this crash?

Thank you 🙏🏻

Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000686d303ed870
0
libswiftCore.dylib
_swift_release_dealloc + 32
1
libswiftCore.dylib
bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 136
2
AppName
<compiler-generated> - Line 4309475464
partial apply for closure #1 in closure #1 in Double.init<A>(_:) + 4309475464
3
libswiftCore.dylib
_swift_release_dealloc + 56
4
libswiftCore.dylib
bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 136
5
libsystem_blocks.dylib
_call_dispose_helpers_excp + 48
6
libsystem_blocks.dylib
_Block_release + 252
7
libdispatch.dylib
_dispatch_client_callout + 20
8
libdispatch.dylib
_dispatch_main_queue_drain + 984
9
libdispatch.dylib
_dispatch_main_queue_callback_4CF + 44
10
CoreFoundation
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
11
CoreFoundation
__CFRunLoopRun + 1996
12
CoreFoundation
CFRunLoopRunSpecific + 608
13
GraphicsServices
GSEventRunModal + 164
14
UIKitCore
-[UIApplication _run] + 888
15
UIKitCore
UIApplicationMain + 340
16
AppName
main.m - Line 18
main + 18
17
(Missing)

From Xcode:

Screenshot 2023-09-26 at 6.10.07 PM.png

Boost

Answer 1

Claude31 OP

Sep ’23

I don't have any idea on my own, but I found this SO thread instructive for the matter: https://stackoverflow.com/questions/62820455/what-is-partial-apply-for-closure1-in-swift

Hope that hemps…

0

Answer 2

DTS Engineer OP

Apple

Sep ’23

I don't think the "partial apply" is actually relevant to the crash. Looking at your backtrace, you can see (frame 8) that the main thread's autorelease pool is being drained — which is to say: autoreleased-but-not-actually-yet-released objects are currently being released. The autorelease works by decrementing the object reference counts (hence frame 4), and that leads to deallocation of objects whose counts actually go to 0 (frame 3).

In the case of an overrelease, the object has already been released and the memory was already returned to the pool for potential re-use, so the object pointer is no longer valid. In that case, the deallocation will attempt to use the invalid pointer, and crash (frame 0).

The chances are that this overrelease was always lurking in your code, but in the past the timing was such that the crash never happened. Even something as harmless as recompiling your app for a new version can change the timing, revealing that lurking problem.

There's no very easy way to debug this. I suggest you start with the advice in these documentation pages:

https://developer.apple.com/documentation/xcode/investigating-memory-access-crashes
https://developer.apple.com/documentation/xcode/investigating-crashes-for-zombie-objects

0