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)

Most upvoted comments

I found a new prefersIncrementalDelivery option in URLSessionTask. I’m going to use it to make sure there are no incremental appends.

I removed lazy in 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 append call 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:

SIGTRAP (#0): Application crash: SIGTRAP (Trace/BPT trap)
Thread 11 Crashed:
0   libswiftCore.dylib         0x0000000183a38d7c  _assertionFailure(_: StaticString, _: String, file: StaticString, line: UInt, flags: UInt32) + 312
1   Foundation                 0x00000001843b2304  __DataStorage.replaceBytes(in: _NSRange, with: UnsafeRawPointer?, length: Int) + 2272
2   Foundation                 0x00000001843b7824  Data.InlineSlice.append(contentsOf: UnsafeRawBufferPointer) + 104
3   Foundation                 0x00000001843bd43c  Data._Representation.append(contentsOf: UnsafeRawBufferPointer) + 520
4   Transfer                   0x00000001031a4f08  TaskFetchOriginalImageData.dataTask(didReceiveData: Data, response: NSURLResponse) + 992  (TaskFetchOriginalImageData.swift:112)
5   Transfer                   0x00000001031a6708  $s4Nuke26TaskFetchOriginalImageDataC04loadF033_0CE7C623FD47A32C42787DE4A50410DELL10urlRequest6finishy10Foundation10URLRequestV_yyctFyAH0F0V_So13NSURLResponseCtcfU_yyYbcfU_TA + 28  (<compiler-generated>:0)
6   Transfer                   0x00000001031a0de4  $s4Nuke17ImagePipelineTaskC5asyncyyyyYbcFyycfU_ + 20  (ImagePipelineTask.swift:21)
7   Transfer                   0x0000000103181704  thunk for @escaping @callee_guaranteed () -> () + 28  (<compiler-generated>:0)
8   libdispatch.dylib          0x00000001911884b4  _dispatch_call_block_and_release + 32
9   libdispatch.dylib          0x0000000191189fdc  _dispatch_client_callout + 20
10  libdispatch.dylib          0x0000000191191694  _dispatch_lane_serial_drain + 672
11  libdispatch.dylib          0x00000001911921e0  _dispatch_lane_invoke + 384
12  libdispatch.dylib          0x000000019119ce10  _dispatch_workloop_worker_thread + 652
13  libsystem_pthread.dylib    0x00000001d6c0fdf8  _pthread_wqthread + 288
14  libsystem_pthread.dylib    0x00000001d6c0fb98  start_wqthread + 8

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.