iOS 12 Crash

[ghost]

• [x] I've read, understood, and done my best to follow the *CONTRIBUTING guidelines.

What did you do?

I tried to download images on iOS 12.

What did you expect to happen?

The images should download and display without crashing.

What happened instead?

The application crashed. Stack trace shows the issue happening within the Alamofire SDK, but we can make requests directly using Alamofire in our app without any issues. So the crash seems to be related specifically to AlamofireImage.

Alamofire Environment

Alamofire version: 4.7.3 Xcode version: 10.0 beta 6 (10L232m) Swift version: 3 Platform(s) running AlamofireImage: iOS 12 macOS version running Xcode: High Sierra 10.13.6 (17G65)

Demo Project

I reproduced on the AlamofireImage Example project. Build and run on the iOS simulator using XCode 10 beta.

Attachments

Here is a screenshot of XCode hitting exception with a malloc error in the console:

Stack trace (I redacted user and password by replacing with "..."): strack_trace.txt

[ghost]

Fyi for anyone else running into this issue, one workaround is to use Alamofire 4.7.2.

[jshier]

I can't reproduce this on our swift4.2 branch. Can you offer more insight into what you're doing? Also, you may want to redact that trace log, as I think it includes some auth credentials. I've removed the link in the mean time. Also, if you can reproduce the crash again, please upload the trace as plain text and not an RTF.

[ghost]

I haven't tried from the swift4.2 branch, we're still using swift 3 in our application. The way I reproduced was running the example project for release 3.3.1 with Alamofire 4.7.3.

I can remove it, but I'm not sure what the auth credentials would be or where they are coming from considering that trace was from the Example project.

Edit: And it was saved as txt, not sure how it got formatted as rtf. I'll fix that.

[jshier]

The swift4.2 branch merely adds support for Swift 4.2, you can still use Swift 3 with it just fine. Both the crash and the trace show some sort of auth credentials being added, are you perhaps behind a proxy or something? I'm not sure where those credentials would be coming from.

[ghost]

Ah right I forgot I had my VPN running. That's probably it then. Though, I'm not sure why the credentials would cause a crash. or why it didn't cause other Alamofire requests to crash (only issue was with images).

(And yep on the same page about swift 4.2, I was just clarifying exactly which branch I was trying in case that would be helpful in debugging.)

[ghost]

Well actually, it was also failing on my device though which was not proxied. I will try to repro again and let you know.

[s-hintz]

I have the same crash without VPN with Xcode 10.0 beta 6 using: Checking out Alamofire at "4.7.3" Checking out AlamofireImage at "3.3.1" *** Checking out AlamofireNetworkActivityIndicator at "2.2.1"

[s-hintz]

After changing the Cartfile, the crash is gone:

github "Alamofire/Alamofire" ~> 4.6 github "Alamofire/AlamofireImage" "swift4.2" github "Alamofire/AlamofireNetworkActivityIndicator" ~> 2.2

[jshier]

@s-hintz Can you post a crash log or stack trace? Are you able to repro using our sample app? Can you try the swift4.2 branch with Alamofire 4.7.3?

[jshier]

Also, what VPN are both of you using?

[ghost]

We both have reproduced without using VPN (@s-hintz said they were NOT using a VPN).

When I tested on the simulator I was running a VPN, but as I said before I also tested on device which was not connected to a VPN or proxy at all. All testing done using the sample project.

I’ve been busy but when I get a chance today I will reupload the stack trace I have in txt format.

[jshier]

@aechap02 My mistake, I read too fast.

I still can't reproduce the crash, and I'm not seeing anything that can crash on that line, unless there's something in the underlying Swift standard library that is the issue. Also, there's no call to authorizationHeader in our sample app, so are you sure you were able to reproduce with that app? I'm not sure how we could be getting a crash in code we never call.

[jshier]

Only difference I can see is that in 4.7.3, I changed the authorizationHeader to a class instead of static method. I'm wondering if perhaps linking the new version with the same compiler leads to issue with the change in signature. @aechap02 do you use Carthage as well? Perhaps if both of you do a carthage update and force it to recompile the dependencies that would fix the issue.

[ghost]

I attached the stack trace and removed the credentials. I am not sure how that function is getting called either, but I am not lying about reproducing with the sample project. I wanted to make 100% sure I could reproduce it there before opening this issue.

Yes I do use Carthage. The sample project doesn't need a Carthage build though, since it includes the Alamofire project as a subproject (just needs the carthage checkout). Anyways, in my other project I had already tried the usual delete carthage folder, clear caches (both derived data and carthage cache), carthage update, etc..

Also I want to note that in the sample project when I swapped to Alamofire version 4.7.2 it worked, and when I changed back to 4.7.3 it failed again. This definitely seems like a weird issue, I'm also wondering if it's like you said a Swift standard lib issue maybe related to iOS 12 beta or Xcode 10 beta.

[jshier]

Give the new Xcode 10 GM a shot and see if anything changes.

From the stack trace you posted, is it possible you're running a modified version of AlamofireImage that added a call to authorizationHeader on line 528 of ImageDownloader.swift? That's the only way I can think that line is getting called. Are the user and password not familiar? As far as I can tell, there's some issue with the string interpolation used to generate the auth header. From what I remember of the unreacted trace, the password may have been corrupted or otherwise bizarrely formatted, as there were a lot of null bytes in it. Please take a look.

[jshier]

Additionally, from the stack:

frame #6: 0x000000010e1dbb7f Alamofire`static Request.authorizationHeader(user=“...", password=“...", self=0x00006000023d50e0) at Request.swift:188 

That says static, but in Alamofire 4.7.3, it's a class method, so this is really strange.

[s-hintz]

@s-hintz Can you post a crash log or stack trace? Are you able to repro using our sample app? Can you try the swift4.2 branch with Alamofire 4.7.3?

As I already wrote, we solved the problem for us, using: github "Alamofire/AlamofireImage" "swift4.2"

And using: Alamofire at "4.7.3"

And I also wrote, that this crash has nothing to do with VPN, because we do not use a VPN. I did not use it a the sample app, but i our own App which worked fine before with Xcode 9. I did not safe the stacktrace. But it was weird, that crash happened in authorizationHeader(user=“...", password=“..." but the it was called from AlamofireImage where I did not see all call to authorizationHeader. I suppose there is some memory corruption. Or a threading problem with the concurrent image cache cleaner thread. (why is cache cleaning concurrent and not serial?) As far as I could see our app did not display any image before the crash. The user parameter contained some garbage with mostly \0. It could be the content of some array. And the password parameter was not accessible in the debugger as far as I remember. So the string interpolation could clearly not use this broken strings.

[Vinzius]

Hi !

Reporting the same issue. I tried with the swift 4.2 branch, and it seems solving the problem.

Just in case you want more logs .

SportEasy(517,0x16d1e3000) malloc: can't allocate region
*** mach_vm_map(size=7608418304) failed (error code=3)
SportEasy(517,0x16d1e3000) malloc: *** set a breakpoint in malloc_error_break to debug

alamofire-image-trace.txt

I couldn't make it crash on the simulator, only the device with the GM.

Anyway, thanks for your work!

[jshier]

I still can't reproduce this on any combination of AlamofireImage / Alamofire version combinations, whether on device or simulator. It sounds like, somehow, the latest updates may fix it, so we'll work towards a new release ASAP.

[ghost]

Interestingly enough, I haven't been able to repro on GM.

@s-hintz Yeah you're right I remember the password not being accessible in debugger as well. And it shows in the stack trace (plus console malloc error) it was not able to interpolate the string. Really seems like that function was being called erroneously, which caused the garbage parameter data. Maybe a strange compiler optimization error or namespace error that results in the wrong function being called. Neither the sample app or our app calls authorizationHeader either so this is strange for sure.

[jshier]

3.4.0 has been released, which seems to fix this issue. If everyone could update and retest, that'd be great. I'm closing this for now but we can reopen it if new instances of this crash are found. Thanks!