Crash in af_inflate

[mlchild]

Crashed: NSOperationQueue 0x17e84a130 :: NSOperation 0x17e8449c0 (QOS: UTILITY) 0 CoreGraphics 0x182347bc4 CGDataProviderCopyData + 236 1 CoreGraphics 0x182347bc4 CGDataProviderCopyData + 236 2 InfatuationSwift 0x100185be0 @objc UIImage.af_inflate() -> () (UIImage+AlamofireImage.swift:110) 3 InfatuationSwift 0x10021a47c static Request.(imageResponseSerializer(imageScale : CGFloat, inflateResponseImage : Bool) -> ResponseSerializer<UIImage, NSError>).(closure #1) (Request+AlamofireImage.swift:99) 4 InfatuationSwift 0x10021a0f8 partial apply for thunk (Request+AlamofireImage.swift) 5 Alamofire 0x10073a390 _TFFC9Alamofire7Request8responseuRxS_22ResponseSerializerTyperFT5queueGSqPSo17OS_dispatch_queue18responseSerializerx17completionHandlerFGVS_8Responsewx16SerializedObjectwx11ErrorObject_TDS0_U_FTT + 436 6 Alamofire 0x100737cfc _TPATFFC9Alamofire7Request8responseuRxS_22ResponseSerializerTyperFT5queueGSqPSo17OS_dispatch_queue18responseSerializerx17completionHandlerFGVS_8Responsewx16SerializedObjectwx11ErrorObject_TDS0_U_FTT + 144 7 Foundation 0x181958510 NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK + 16 8 Foundation 0x1818aa900 -[NSBlockOperation main] + 96 9 Foundation 0x18189aed8 -[__NSOperationInternal _start:] + 604 10 Foundation 0x18195a904 NSOQSchedule_f + 224 11 libdispatch.dylib 0x1809e947c _dispatch_client_callout + 16 12 libdispatch.dylib 0x1809f54c0 _dispatch_queue_drain + 864 13 libdispatch.dylib 0x1809ecf80 _dispatch_queue_invoke + 464 14 libdispatch.dylib 0x1809f7390 _dispatch_root_queue_drain + 728 15 libdispatch.dylib 0x1809f70b0 _dispatch_worker_thread3 + 112 16 libsystem_pthread.dylib 0x180c01470 _pthread_wqthread + 1092 17 libsystem_pthread.dylib 0x180c01020 start_wqthread + 4

Not sure exactly when the crash occurred, but I got this from Crashlytics. Appears to be after the line CGDataProviderCopyData(CGImageGetDataProvider(CGImage))

[cnoon]

Unfortunately there's not enough information to go on here to be helpful. I'm going to close this issue out for now since there's no possible action item at the moment. If you can provide more information to go on, such as a reproduction case or a detailed explanation of how you think this crash could have occurred, then I'll happily re-open the issue and help you investigate further.

Cheers. 🍻

[mlchild]

Sorry for the lack of detail, I was not present when the crash occurred and this is all I got from Crashlytics. Thanks for taking a look.

[sibe7691]

@mlchild I got this issue too. Crashed: NSOperationQueue 0x1fd8273d0 :: NSOperation 0x1fc02f290 (QOS: UTILITY) 0 CoreGraphics 0x1839b7bc4 CGDataProviderCopyData + 236 1 CoreGraphics 0x1839b7bc4 CGDataProviderCopyData + 236 2 AlamofireImage 0x100ae0980 @objc UIImage.af_inflate() -> () (UIImage+AlamofireImage.swift:110) 3 AlamofireImage 0x100ad80bc static Request.(imageResponseSerializer(imageScale : CGFloat, inflateResponseImage : Bool) -> ResponseSerializer<UIImage, NSError>).(closure #1) (Request+AlamofireImage.swift:98) 4 AlamofireImage 0x100ad7d38 partial apply for thunk (Request+AlamofireImage.swift) 5 Alamofire 0x100a39704 Request.(response<A where ...> (queue : OS_dispatch_queue?, responseSerializer : A, completionHandler : (Response<A.SerializedObject, A.ErrorObject>) -> ()) -> Self).(closure #1) (ResponseSerialization.swift) 6 Alamofire 0x100a37070 partial apply for Request.(response<A where ...> (queue : OS_dispatch_queue?, responseSerializer : A, completionHandler : (Response<A.SerializedObject, A.ErrorObject>) -> ()) -> Self).(closure #1) (ResponseSerialization.swift) 7 Foundation 0x182fc8540 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16 8 Foundation 0x182f1a870 -[NSBlockOperation main] + 96 9 Foundation 0x182f0ae48 -[__NSOperationInternal _start:] + 604 10 Foundation 0x182fca934 __NSOQSchedule_f + 224 11 libdispatch.dylib 0x18205947c _dispatch_client_callout + 16 12 libdispatch.dylib 0x1820654c0 _dispatch_queue_drain + 864 13 libdispatch.dylib 0x18205cf80 _dispatch_queue_invoke + 464 14 libdispatch.dylib 0x182067390 _dispatch_root_queue_drain + 728 15 libdispatch.dylib 0x1820670b0 _dispatch_worker_thread3 + 112 16 libsystem_pthread.dylib 0x182271470 _pthread_wqthread + 1092 17 libsystem_pthread.dylib 0x182271020 start_wqthread + 4

[elikohen]

@cnoon We at Letgo are having also this crash, never happened on development but we can see it on crashlytics.

Crashed: NSOperationQueue 0x18dd9df0 :: NSOperation 0x4df13390
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000000

Trace:
0  CoreGraphics                   0x26afe7d0 x_malloc + 15
1  libsystem_malloc.dylib         0x347c54cf malloc + 54
2  CoreGraphics                   0x26b2002f CGDataProviderCopyData + 198
3  AlamofireImage                 0xb9d594 @objc UIImage.af_inflate() -> () (UIImage+AlamofireImage.swift:110)
4  AlamofireImage                 0xb936ac static Request.(imageResponseSerializer(imageScale : CGFloat, inflateResponseImage : Bool) -> ResponseSerializer<UIImage, NSError>).(closure #1) (Request+AlamofireImage.swift:99)
5  AlamofireImage                 0xb92bc4 partial apply for static Request.(imageResponseSerializer(imageScale : CGFloat, inflateResponseImage : Bool) -> ResponseSerializer<UIImage, NSError>).(closure #1) (Request+AlamofireImage.swift)
6  AlamofireImage                 0xb92c50 partial apply for thunk (Request+AlamofireImage.swift)
7  Alamofire                      0xa80e54 Request.(response<A where ...> (queue : OS_dispatch_queue?, responseSerializer : A, completionHandler : (Response<A.SerializedObject, A.ErrorObject>) -> ()) -> Self).(closure #1) (ResponseSerialization.swift)
8  Alamofire                      0xa7e578 partial apply for Request.(response<A where ...> (queue : OS_dispatch_queue?, responseSerializer : A, completionHandler : (Response<A.SerializedObject, A.ErrorObject>) -> ()) -> Self).(closure #1) (ResponseSerialization.swift)
9  Foundation                     0x275c40fd __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 8
10 Foundation                     0x2752efc5 -[NSBlockOperation main] + 148
11 Foundation                     0x27521845 -[__NSOperationInternal _start:] + 768
12 Foundation                     0x275c6a57 __NSOQSchedule_f + 186
13 libdispatch.dylib              0x346a35d9 _dispatch_queue_drain$VARIANT$mp + 948
14 libdispatch.dylib              0x346a30a9 _dispatch_queue_invoke$VARIANT$mp + 84
15 libdispatch.dylib              0x346a50d3 _dispatch_root_queue_drain + 330
16 libdispatch.dylib              0x346a61fb _dispatch_worker_thread3 + 106
17 libsystem_pthread.dylib        0x34816e25 _pthread_wqthread + 668
18 libsystem_pthread.dylib        0x34816b78 start_wqthread + 8

Also this it what was happening in the main thread at the moment of the crash:

com.apple.main-thread
0  libsystem_kernel.dylib         0x34786568 semaphore_wait_trap + 8
1  libdispatch.dylib              0x346a67ed _dispatch_group_wait_slow + 204
2  CoreUI                         0x2c5202f9 -[_CSIRenditionBlockData expandCSIBitmapData:fromSlice:makeReadOnly:] + 588
3  CoreUI                         0x2c524083 csiCompressImageProviderCopyImageBlockSetWithOptions + 1106
4  CoreGraphics                   0x26b07d77 CGImageProviderCopyImageBlockSetWithOptions + 178
5  QuartzCore                     0x297be6d1 CA::Render::create_image(CGImage*, CGColorSpace*, unsigned int) + 696
6  QuartzCore                     0x297bdb5b CA::Render::copy_image(CGImage*, CGColorSpace*, unsigned int, double) + 314
7  QuartzCore                     0x297be407 CA::Render::prepare_image(CGImage*, CGColorSpace*, unsigned int, double) + 18
8  QuartzCore                     0x29792cd5 CA::Layer::prepare_commit(CA::Transaction*) + 372
9  QuartzCore                     0x297921cf CA::Context::commit_transaction(CA::Transaction*) + 230
10 QuartzCore                     0x29791fd1 CA::Transaction::commit() + 324
11 UIKit                          0x29d6d361 _UIApplicationHandleEventQueue + 1384
12 CoreFoundation                 0x2688cfd7 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
13 CoreFoundation                 0x2688c3eb __CFRunLoopDoSources0 + 222
14 CoreFoundation                 0x2688aa69 __CFRunLoopRun + 768
15 CoreFoundation                 0x267d7b31 CFRunLoopRunSpecific + 476
16 CoreFoundation                 0x267d7943 CFRunLoopRunInMode + 106
17 GraphicsServices               0x2dbb7051 GSEventRunModal + 136
18 UIKit                          0x29dcd6f1 UIApplicationMain + 1440
19 LetGo                          0x1d99bc main (AppDelegate.swift:27)
20 libdyld.dylib                  0x346d4aaf <redacted> + 2

Thank you in advance

[jomnius]

Same crash (64 times in 5 releases between Jul - Sep), never managed to catch this in development. Currently using AlamofireImage 2.4.1 version, but was there earlier, too.

Hockeyapp crash report is pointing to CGDataProviderCopyData line of code:

    public func af_inflate() {
        guard !af_inflated else { return }

        af_inflated = true
        CGDataProviderCopyData(CGImageGetDataProvider(CGImage))
    }

The error code is "Exception Codes: SEGV_ACCERR at 0x0", which seems to say there is memory issue with CGDataProviderCopyData method. I'm guessing CGImageGetDataProvider was failing for unknown reason. Any ideas?

Thread 14 Crashed:
0   CoreGraphics                         0x0000000183f07ad4 CGDataProviderCopyData + 236
1   AlamofireImage                       0x0000000100f3885c @objc (extension in AlamofireImage):__ObjC.UIImage.af_inflate () -> () (UIImage+AlamofireImage.swift:109)
2   AlamofireImage                       0x0000000100f2fac4 static (extension in AlamofireImage):Alamofire.Request.(imageResponseSerializer (imageScale : CoreGraphics.CGFloat, inflateResponseImage : Swift.Bool) -> Alamofire.ResponseSerializer<__ObjC.UIImage, __ObjC.NSError>).(closure #1) (Request+AlamofireImage.swift:97)
3   AlamofireImage                       0x0000000100f2f2d0 partial apply forwarder for reabstraction thunk helper from @callee_owned (@owned __ObjC.NSURLRequest?, @owned __ObjC.NSHTTPURLResponse?, @owned __ObjC.NSData?, @owned __ObjC.NSError?) -> (@owned Alamofire.Result<__ObjC.UIImage, __ObjC.NSError>) to @callee_owned (@owned __ObjC.NSURLRequest?, @owned __ObjC.NSHTTPURLResponse?, @owned __ObjC.NSData?, @owned __ObjC.NSError?) -> (@out Alamofire.Result<__ObjC.UIImage, __ObjC.NSError>) (Request+AlamofireImage.swift:0)
4   Alamofire                            0x0000000100df8f8c Alamofire.Request.(response <A where A: Alamofire.ResponseSerializerType> (queue : __ObjC.OS_dispatch_queue?, responseSerializer : A, completionHandler : (Alamofire.Response<A.SerializedObject, A.ErrorObject>) -> ()) -> Self).(closure #1) (ResponseSerialization.swift:122)
5   Alamofire                            0x0000000100df68f8 partial apply forwarder for Alamofire.Request.(response <A where A: Alamofire.ResponseSerializerType> (queue : __ObjC.OS_dispatch_queue?, responseSerializer : A, completionHandler : (Alamofire.Response<A.SerializedObject, A.ErrorObject>) -> ()) -> Self).(closure #1) (ResponseSerialization.swift:0)
6   Foundation                           0x0000000183518540 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 12
7   Foundation                           0x000000018346a870 -[NSBlockOperation main] + 92
8   Foundation                           0x000000018345ae48 -[__NSOperationInternal _start:] + 600
9   Foundation                           0x000000018351a934 __NSOQSchedule_f + 220
10  libdispatch.dylib                    0x00000001825a947c _dispatch_client_callout + 12
11  libdispatch.dylib                    0x00000001825b54c0 _dispatch_queue_drain + 860
12  libdispatch.dylib                    0x00000001825acf80 _dispatch_queue_invoke + 460
13  libdispatch.dylib                    0x00000001825b7390 _dispatch_root_queue_drain + 724
14  libdispatch.dylib                    0x00000001825b70b0 _dispatch_worker_thread3 + 108
15  libsystem_pthread.dylib              0x00000001827c1470 _pthread_wqthread + 1088
16  libsystem_pthread.dylib              0x00000001827c1020 start_wqthread + 0

[cnoon]

Okay...re-opening.

Everything I can find online here leads me down a path of memory corruption or running out of memory. We (Nike) have an app in production right now (millions of users) that relies heavily on this inflation logic to power the app. It's full of large and small image content all over the app. We don't have a trace of this crash appearing anywhere in our crash reports.

This is awesome! But a bit frustrating as well because I don't know where the issue lies.

I'm inclined right now to say there's something wrong on the client implementation, but I have absolutely no idea what it would be or if there's something that you are all doing in your app that we're not doing in ours. I'm simply pulling at straws here because there's nothing to really go on.

Has anyone spent time trying to repro this in the debugger with zombies enabled? That seems to be the most common way to debug this particular issue. I don't have any project that can repro any of this behavior and there's nothing that I can investigate in the crash report at this point.

I'm open to suggestions here. I re-opened this issue for you. I'm willing to help out, but there's no actionable item for me at this point. You all are going to have to help find something else for me to try to investigate...

[meisbedi]

I experienced the same problem with my application. I was able, to reproduce the crash. I narrowed the issue down to a specific jpeg file.

But I have no idea, what to look for, to figure out, what created the problem with this file in the first place.

[meisbedi]

Further testing revealed, that the problem does not lie with the jpeg file, but the url to the image .../Joss*20Stone/folder.jpg crashes .../Joss_Stone/folder.jpg does not crash.

I have hundreds of cells in my tableview with urls that mach the pattern ".../xyz*20abc/folder.jpg" that do not create an issue. Only the one mentioned above.

Go figure...

[cnoon]

For everyone still having issues here, it's almost certainly due to the application running out-of-memory. Please see #141 for more details.

[onato]

I am seeing my app killed by the OS. After profiling I see that there is a lot of memory being allocated in this method:

[cnoon]

Yes, that method inflate a compressed image so that it can be rendered to your display. The entire point is to allocate the memory. If your app is being terminated b/c too much memory is being used, you need to clean up your image data as you progress through your application.

[AmineG]

Similar issue here with this crash stack :

# Issue #: 16
# Issue ID: 580777620aeb16625bab893e
# Session ID: aa221da685f241efac8ad6c02b7ddbd8
# Date: 2016-10-19T13:35:16Z
# OS Version: 10.0.2 (14A456)
# Device: iPhone 7 Plus
# RAM Free: 3.1%
# Disk Free: 59.4%

#14. Crashed: NSOperationQueue 0x172822500 :: NSOperation 0x172a44aa0 (QOS: UTILITY)
0  libsystem_kernel.dylib         0x185ac2014 __pthread_kill + 8
1  libsystem_pthread.dylib        0x185b89460 pthread_kill + 112
2  libsystem_c.dylib              0x185a363f4 abort + 140
3  libsystem_malloc.dylib         0x185b06a38 _nano_vet_and_size_of_live + 330
4  libsystem_malloc.dylib         0x185b07db8 nano_free + 220
5  CoreFoundation                 0x186aa3e8c _CFRelease + 1264
6  AlamofireImage                 0x100564720 @objc UIImage.af_inflate() -> () (UIImage+AlamofireImage.swift:116)
7  AlamofireImage                 0x10055b21c static Request.(imageResponseSerializer(imageScale : CGFloat, inflateResponseImage : Bool) -> ResponseSerializer<UIImage, NSError>).(closure #1) (Request+AlamofireImage.swift:99)
8  AlamofireImage                 0x10055cff8 partial apply for thunk (Request+AlamofireImage.swift)
9  Alamofire                      0x10042fca8 Request.(response<A where ...> (queue : OS_dispatch_queue?, responseSerializer : A, completionHandler : (Response<A.SerializedObject, A.ErrorObject>) -> ()) -> Self).(closure #1) (ResponseSerialization.swift)
10 Alamofire                      0x100430284 partial apply for Request.(response<A where ...> (queue : OS_dispatch_queue?, responseSerializer : A, completionHandler : (Response<A.SerializedObject, A.ErrorObject>) -> ()) -> Self).(closure #1) (ResponseSerialization.swift)
11 Foundation                     0x1875b57e4 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
12 Foundation                     0x1874fa358 -[NSBlockOperation main] + 96
13 Foundation                     0x1874ea954 -[__NSOperationInternal _start:] + 620
14 Foundation                     0x1875b7b90 __NSOQSchedule_f + 228
15 libdispatch.dylib              0x18597d1c0 _dispatch_client_callout + 16
16 libdispatch.dylib              0x18598b444 _dispatch_queue_serial_drain + 928
17 libdispatch.dylib              0x1859809a8 _dispatch_queue_invoke + 652
18 libdispatch.dylib              0x18598d38c _dispatch_root_queue_drain + 572
19 libdispatch.dylib              0x18598d0ec _dispatch_worker_thread3 + 124
20 libsystem_pthread.dylib        0x185b852c8 _pthread_wqthread + 1288
21 libsystem_pthread.dylib        0x185b84db4 start_wqthread + 4

--

I am using Alamofire 2.5.0 with Xcode 8 / Swift 2.3

Any solution ?

[odemolliens]

Crashed: com.apple.main-thread

0  CoreGraphics                   0x183547ad4 CGDataProviderCopyData + 236

1  CoreGraphics                   0x183547ad4 CGDataProviderCopyData + 236

2  AlamofireImage                 0x100a13fb0 @objc UIImage.af_inflate() -> () (UIImage+AlamofireImage.swift:110)

9  AVFoundation                   0x1888f0408 -[AVCaptureStillImageOutput handleNotification:payload:] + 1740

10 CoreFoundation                 0x182154f84 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20

11 CoreFoundation                 0x1821548bc __CFRunLoopDoBlocks + 308

12 CoreFoundation                 0x182152d04 __CFRunLoopRun + 1960

13 CoreFoundation                 0x18207cc50 CFRunLoopRunSpecific + 384

14 GraphicsServices               0x183964088 GSEventRunModal + 180

15 UIKit                          0x18735e088 UIApplicationMain + 204

17 libdispatch.dylib              0x181c1a8b8 (Missing)

Same here

Related to OOM Only 22.00 MB free ram on device Image is less than 1.00 MB

[nickmshelley]

We're encountering this issue too, and we spent a lot of time trying to narrow down the problem. We narrowed it down to a specific image causing the crash. In fact, I can get it to crash without even using the library. If I create a test project and run the following code on an iPhone 7+ with the latest OS (it doesn't crash on simulator) using the attached image, it will crash every time:

let crashy = UIImage(named: "crashy.jpg")
_ = crashy?.cgImage?.dataProvider?.data

We can't figure out what is wrong with this image. We've tried using online metadata validators and comparing this image with both larger and smaller renditions that don't crash, and everything seems identical.

Now, I realize that this obviously means the underlying bug isn't with the library (I'm suspecting it's a CGImage bug). But because we don't know what else to change, our only option is to not use the library, so I'm putting this info here in case someone can figure out what we can change to use the library, or maybe there's a less performant way to inflate images that we could use in a fork, or something, because we really like what the library provides.

I hope this info can help someone smarter than me find the problem. 😄

[nickmshelley]

Also @meisbedi, I'd suspect your Joss*20Stone/folder.jpg image that crashes has a similar problem, since your situation seems to be similar to ours.

[blixt]

I've seen this issue in our logs too. The issue, as previously stated is that memory runs out on the device. The reason you can identify specific images as the culprit is probably due to the pixel sizes of the images (not their file size).

For example, a 5000x5000 image with simple graphics can be less than 100 kB in PNG format. However, when inflated (turned into raw bitmap data), iOS needs to allocate (at least) 5000*5000*4 bytes for that image, which is almost 100 MB, or three orders of magnitude increase in memory use!

The solution here is to serve smaller images to the clients so they don't have to process that amount of raw pixel data. The raw memory footprint increases exponentially with pixel size, so even small decreases in size can give you big gains. For example, changing a 5000x5000 image to 4000x4000, you've reduced the footprint by about 35%.

[fer662]

I came across this because I turned on guard_malloc randomly just to do a sanity pass on some memory issues that arose with a recent release. I got this message and a break within af_inflate. The offending image in this case wasn't big enough to justify a buffer that big.

GuardMalloc[xxx-22081]: Attempting excessively large memory allocation: 134217728 bytes GuardMalloc[xxx-22081]: If you really wanted to allocate so much memory, launch your executable with the environment variable MALLOC_PERMIT_INSANE_REQUESTS set to any value to circumvent this check. GuardMalloc[xxx-22081]: Explicitly trapping into debugger!!!

[sorinmiroiu97]

Hey guys. So i've encountered this crash as well. Thing is like @meisbedi said I also narrowed it down to ONE image from all of the many possibilities of images. But thing is now i'm not so sure anymore because with the same code on the device it crashes EVERYTIME, but on the simulator where i have again the exact same code it doesn't crash. I've already started on implementing my own networking library but in the meantime it would be nice to see some kind of a fix or an answer to this. Thanks in advance

[blixt]

@soryncrash13 Since this is a memory related issue, that's not surprising – your simulator has access to a lot more memory than your phone! See my comment.

[cnoon]

Yep, @blixt is spot on. You need to be a bit careful loading massive images onto mobile devices. You'll simply run out of memory. Right now, AFI assumes you have already done the leg work to make sure you aren't loading 10k x 10k images on your own. Apple has many other avenues to load images with that high of a resolution.

[sorinmiroiu97]

Hey @blixt and @cnoon thanks for your answers. Unfortunately it's not anything related to running out of memory. I mean after the app crashed 3 times in a row for uploading a jped image (which is not even 4mb) the 4th time it did upload it and never had any issue with that image again. It's just weird, idk. I'm not loading high res images. All the images i upload in the app are compressed and their size is massively reduced since the user base tend to have 25mb per image so it would be insane to even consider downloading such a file. And all the lists are paginated with 10 rows at a time... If you do have any other tips please let me know :) Thank you so much again

[iChetna]

i got issue in version 3.5.2 Fatal Exception: NSMallocException 0 CoreFoundation 0x1ba010518 exceptionPreprocess 1 libobjc.A.dylib 0x1b91eb9f8 objc_exception_throw 2 Foundation 0x1baa7a794 _NSInitializePlatform 3 CoreFoundation 0x1b9f47af4 CFReallocationFailed 4 CoreFoundation 0x1b9f47a94 CFSafelyReallocate 5 CoreFoundation 0x1b9f67194 CFDataGrow 6 CoreFoundation 0x1b9f66f60 CFDataSetLength 7 CoreGraphics 0x1bbc82464 CGDataProviderCopyData 8 AlamofireImage 0x102df7cec UIImage.af_inflate() (UIImage+AlamofireImage.swift:103) 9 AlamofireImage 0x102df1758 closure #1 in static DataRequest.imageResponseSerializer(imageScale:inflateResponseImage:) () 10 AlamofireImage 0x102ddac78 thunk for @escaping @callee_guaranteed (@in_guaranteed URLRequest?, @guaranteed NSHTTPURLResponse?, @guaranteed Data?, @guaranteed Error?) -> (@owned Result) () 11 Alamofire 0x102f9643c closure #1 in DataRequest.response(queue:responseSerializer:completionHandler:) () 12 Alamofire 0x102f790a0 thunk for @escaping @callee_guaranteed () -> () () 13 Foundation 0x1baa74f68 NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK 14 Foundation 0x1ba981420 -[NSBlockOperation main] 15 Foundation 0x1ba980908 -[NSOperationInternal _start:] 16 Foundation 0x1baa76cec NSOQSchedule_f 17 libdispatch.dylib 0x1b9a321cc _dispatch_block_async_invoke2 18 libdispatch.dylib 0x1b9a517d4 _dispatch_client_callout 19 libdispatch.dylib 0x1b9a28c34 _dispatch_continuation_pop$VARIANT$armv81 20 libdispatch.dylib 0x1b9a28314 _dispatch_async_redirect_invoke 21 libdispatch.dylib 0x1b9a349d4 _dispatch_root_queue_drain 22 libdispatch.dylib 0x1b9a35248 _dispatch_worker_thread2 23 libsystem_pthread.dylib 0x1b9c311b4 _pthread_wqthread 24 libsystem_pthread.dylib 0x1b9c33cd4 start_wqthread