Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Subtype: KERN_INVALID_ADDRESS at 0x00000000
Of course the crash log is longer, but I haven't managed to symbolicate it unfortunately (lost the old app and dsym)
My question is however, since this happens:
- only to a very small minority of users
- immediately after launching the app
- but on those device, it happens every time, even after updating the app, even after reinstalling it, even after reboot
Could it be some faults on how xamarin packaged stuff works at run time, with some devices ?
I've read around that apps realized with other frameworks can give this problem, hence my question.
Today, we have checked this issue with:
XS 4.2.3(build 29)
We are successfully able to deploy the iOS application on Devices/Simulators. Could you please attach the sample or device info? Which you are using so that we can reproduce this issue.
Please consider that I don't have a way to repro the problem, since I guess 99% of the users don't see this. But I had a few reports in the past of just installed apps crashing only on certain devices. And I think I've read on stack overflow of memory alignment issues (or/ and similar stuff) which could be traced back to some Xamarin versions.
So at this point what I'm asking is:
- could this be remotely due to xamarin ?
- any way for me to check anything, test anything ?
My XS version is stable 4.2.2 build 2
I'm not in front if the computer, but MT version is stable too.
I edit and debug from the PC, but distribution is obviously done on the Mac.
There is not enough information about this to determine where the problem is - it could be a problem with Xamarin.iOS, it could be a problem in iOS itself or it could be a problem in your code.
A crash report would help (even if it's not symbolicated, you'd still be able to determine if it was a stack overflow for instance).
It would also help to find out what's special about these users' devices, i.e. does it only happen with a specific iOS version / device / culture / localization / etc?
Yes, I understand. Thanks
I am going through heaps of backups and I might have found the relevant DSYM . I'll attache the crash report here first.
I think I might have been able to symbolicate the most relevant part with atos...
I'll attach the result... it seems to me the cause is the Google Ad Bindings (I got them from Monotouch Bindings github) ?
But I don't understand why it crashes this way...
1. I used the attachment from comment 5 and ran it through the symbolicatecrash script from Apple (it's somewhere inside Xcode.app, I usually just run 'find' from a terminal to find it).
2. I believe the Build -> Archive menu option is what you want.
2. What, there's a build->archive in XS too ? :) Great ! (feeling stupid)
1. Ah, OK, not sure I understand it fully, I thought atos was already symbolicating everything possible.
So the part I symbolicated with atos is only partial to my code, while symbolicating with xcode gets system libraries ?
Regarding the issue at hand, what I was referring in my previous comment was a situation where linking the admob binding that I got from the mt bindings github crashed right at the start, but only on iOS 6 simulator.
1. atos is a very "basic" command, you need to tell it the dSYMs to use, while symbolicatecrash (and Xcode) will automatically look for the dSYMs (using Spotlight). This is probably the reason for the difference you're seeing.
After launching and passing my custom dSYM folder, it gave me the same output as yours. I would have expected to symbolicate those addresses that atos managed to link to Admob. Uhm...
This because the topmost line regarding my app says (in atos):
-[GADCachedFile beginFetchWithCacheBuster:] (in LogicGames) (GADCachedFile.m:166)
Ok here is my reasoning, and why I filed a bug
I couldn't symbolicate the bug report properly with symbolicatecrash, only with atos, don't know why.
Couldn't it be that storekit returns the state of in app purchase, which removes ads, which in turn in my code fires methods regarding admob ?
I'm asking because apparently admob bindings had serious problems linking, evident on some devices on tests I've done.
Hence my question regarding XS and how it could link it (or maybe how the bindings work)
Otherwise it's obviously something outside xamarin scope.
I'm also extremely puzzled by the fact that the user says it happens even after reinstalling and with airplane mode on. Cached store info ?
Rolf, I see why I didn't notice the archive command when I looked for it. XS, together with the VS plugin, messed up solution and project configurations (I reported in another bug). So when I chose distribution it was linked to some other non distro config, which didn't have Archive as an option.
Too many moving parts...
You could also ask the user to get the device console output as described here: https://developer.apple.com/library/ios/qa/qa1747/_index.html
In a separate note it would not surprise me if iOS caches store info. Does it still happen if the user logs out out and/or uses a different Apple ID on his device?
Ok apparently this is not the bug I was referring to - the one which goes away by linking sdk assemblies...I can't find it anymore, it was reported in the forums.
Although it looked similar and the workaround seemed to work, it's something else, unrelated to Xamarin.