Nuke: Crash in `TaskFetchOriginalImageData.swift`
Hi Alexander, thanks for the great library.
I noticed a crash related to TaskFetchOriginalImageData.swift:107 (data.append(chunk))
Could it be related to private lazy var data = Data()? I thought if it’s not thread-safe and if it’s possible to access it from multiple threads then that might be the cause.
Let me know if you need more information
SIGTRAP (#0): Application crash: SIGTRAP (Trace/BPT trap)
Thread 8 Crashed:
0 libswiftFoundation.dylib 0x0000000185565ee4 specialized __DataStorage.init(bytes: UnsafeMutableRawPointer?, length: Int, copy: Bool, deallocator: (UnsafeMutableRawPointer, Int)?, offset: Int) + 360
1 libswiftFoundation.dylib 0x0000000185451714 Data.InlineSlice.ensureUniqueReference() + 156
2 libswiftFoundation.dylib 0x000000018545a944 Data.InlineSlice.append(contentsOf: UnsafeRawBufferPointer) + 40
3 libswiftFoundation.dylib 0x000000018545b960 Data._Representation.append(contentsOf: UnsafeRawBufferPointer) + 580
4 Transfer 0x0000000105192228 TaskFetchOriginalImageData.dataTask(didReceiveData: Data, response: NSURLResponse) + 900 /Users/vagrant/git/SourcePackages/checkouts/Nuke/Sources/Core/Tasks/TaskFetchOriginalImageData.swift:107
5 Transfer 0x0000000105193e10 partial apply for closure #1 () in closure #1 (Data, NSURLResponse) in TaskFetchOriginalImageData.loadData(urlRequest: URLRequest, finish: ()) + 28 <compiler-generated>:0
6 Transfer 0x0000000105170f10 thunk for @escaping @callee_guaranteed () -> () + 28 <compiler-generated>:0
7 libdispatch.dylib 0x00000001809fae68 _dispatch_call_block_and_release + 32
8 libdispatch.dylib 0x00000001809fca2c _dispatch_client_callout + 20
9 libdispatch.dylib 0x0000000180a04124 _dispatch_lane_serial_drain + 668
10 libdispatch.dylib 0x0000000180a04c80 _dispatch_lane_invoke + 392
11 libdispatch.dylib 0x0000000180a0f500 _dispatch_workloop_worker_thread + 648
12 libsystem_pthread.dylib 0x00000001f1d1a0bc _pthread_wqthread + 288
13 libsystem_pthread.dylib 0x00000001f1d19e5c start_wqthread + 8
SIGTRAP (#0): Application crash: SIGTRAP (Trace/BPT trap)
Thread 10 Crashed:
0 libswiftFoundation.dylib 0x00000001db9b2ee4 0x1db892000 + 1183460
1 libswiftFoundation.dylib 0x00000001db89e6ec 0x1db892000 + 50924
2 libswiftFoundation.dylib 0x00000001db8a791c 0x1db892000 + 88348
3 libswiftFoundation.dylib 0x00000001db8a8938 0x1db892000 + 92472
4 Transfer 0x000000010450a228 TaskFetchOriginalImageData.dataTask(didReceiveData: Data, response: NSURLResponse) + 900 /Users/vagrant/git/SourcePackages/checkouts/Nuke/Sources/Core/Tasks/TaskFetchOriginalImageData.swift:107
5 Transfer 0x000000010450be10 partial apply for closure #1 () in closure #1 (Data, NSURLResponse) in TaskFetchOriginalImageData.loadData(urlRequest: URLRequest, finish: ()) + 28 <compiler-generated>:0
6 Transfer 0x00000001044e8f10 thunk for @escaping @callee_guaranteed () -> () + 28 <compiler-generated>:0
7 libdispatch.dylib 0x00000001d6e3ae6c 0x1d6e39000 + 7788
8 libdispatch.dylib 0x00000001d6e3ca30 0x1d6e39000 + 14896
9 libdispatch.dylib 0x00000001d6e44124 0x1d6e39000 + 45348
10 libdispatch.dylib 0x00000001d6e44c80 0x1d6e39000 + 48256
11 libdispatch.dylib 0x00000001d6e4f500 0x1d6e39000 + 91392
12 libsystem_pthread.dylib 0x000000024833c0bc 0x24833b000 + 4284
13 libsystem_pthread.dylib 0x000000024833be5c 0x24833b000 + 3676
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 27 (21 by maintainers)
I found a new
prefersIncrementalDeliveryoption inURLSessionTask. I’m going to use it to make sure there are no incremental appends.I removed
lazyin Nuke 11.1.0. It’s not mentioned in the release notes because I’m not sure it does anything. I would appreciate if you could update and let me know if the crashes stop.I’n going to try getting rid of the
appendcall entirely in 11.5, at least for non-progressive images. It should also reduce number of memory allocations. It might partially mitigate the issue, but it appears to be general memory allocation issue / lack of available memory.While handling local files ourselves reduced the crash for us, we still see it happening occasionally:
Thanks. By looking at the code, it is confined to the queue and this code hasn’t changed in a long while. Will need to investigate more.