-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native Crash with Fatal signal 6 (SIGABRT), code -6 #3892
Comments
@daniels7 can you produce the problem in a new project? or does it seem like it is specific to your app? I am wondering how this would be related to app bundles, as it seems to be a problem with Mono in general:
Does the problem happen with APKs as well? |
@jonathanpeppers The strange thing is that a Release Build from Visual Studio to Device doesn't crash. I don't see any difference between a release build and a packaged and signed Build for Upload, do you? |
I'll try to create a repro project later, but it can take some time. I'd be happy if you could still try to investigate the issue until then |
I checked out some different approaches now and the problem is not related to an update of Xamarin.Android or Visual Studio, as the App starts working again if I rollback every code changes since the last release. The main difference since then is a large number of package Updates and the migration from packages.config to the .csproj PackageReferences. Sadly the native crash isn't helpful at all in finding out what's wrong. |
I can't find any differences between the aab that is generated and split up when distributing the release version from VS onto my phone and the signed aab that is generated and uploaded to the playstore. The first one works well and the other one crashes. |
Can you record a diagnostic MSBuild log of the one that works vs the one that doesn't? |
With your informations I can enable the verbose output for the MSBuild-Taks inside VS, so for the build that works. Will it work with using MSBuild from Commandline as well? I have to use MSBuild from Commandline to create the signed AAB for upload. |
You might just try doing them both command-line, such as:
Zip up the two binlog files, thanks! |
I'll try to do so, thank you very much :) |
Sadly I can't reproduce the problem locally. It's ridiculous: If I build the app locally and directly install it (no matter if aab or apk or whatever) it works great. If I upload the very same aab (just signed) to Google's Internal Test and download the App from Play Store I'll get those native crashes. I don't see any way to debug that since the problem seems to be something else, not MSBuild. @jonathanpeppers Do you have any other clues? :( |
Will google serve exactly the same architecture and so on to my device like the local install by MSBuild does? |
When you send to Google Play, are you building the same configuration? Can you attach the full
|
On my last try I used exactly the same output aab (Just Signed vs Unsigned, but that shouldn't be a difference). Sadly the binlog contains a lot of sensitive Data, so I'd prefer not to share it, especially not in public. It shouldn't be related to masbuild though due to the same AAB working on local install and not working on Google Install (same goes for APK). I'd guess it has something to do with architectures, but I'm not sure, as the problem is very puzzling. |
There is the log, generated as you requested |
Are you using AOT in some form?
Does it work if you turn that off? It might be a combination of using an App Bundle with AOT/Profiled AOT. |
YAAAY, You are so great! :D |
Do you think that the times you had AOT+LLVM on it was failing? And the other times it was working? Or is it the combination of AOT+LLVM+App Bundle? |
I don't think that the App Bundle is related since the APK I uploaded to google in between crashed as well. Since the problem appeared with the numerous Nuget Package Upgrades we did the Problem seems to be AOT+LLVM+PackageUpdates |
@jonathanpeppers Sadly turning off AOT and LLVM broke the VS feature of Bundling assemblies in native Code (though the checkbox is still checked) and I could easily decompile our App now :( |
You probably don't need all 3 options:
What if you tried AOT by itself? |
Will it prevent decompiling? With just mkbundle I had a .so file which just is a gzipped dll with everything inside and fully decompilable code (including comments and everything) |
Next tests: |
The problem is definitely the AOT |
AOT is what converts your IL into assembly code. It makes it harder for someone to figure out the original C# source of your app but does not prevent it--even with some kind of obfuscation. I don't know what your app is, but it might not be worth worrying about. I think AOT is likely the culprit here, though. 😞 |
Yes, I think so too, though it seems to be related to the package updates as well, since the App starts working again on a rollback. Do you have any ideas on how to find out the exact problem? |
@jonathanpeppers Do you have an idea on how to fix the AOT-Crashes? |
Sorry @daniels7 we will need someone on the Mono team to investigate, I'll get someone to take a look. |
@daniels7 can you reproduce the issue in a small project and upload it here? The Mono team will need that to investigate. |
@jonathanpeppers That'll be a bit difficult since the Crash is just reproducible if you upload the App to Google Play and download it through the store so I'd have to create a new App just for this including store entry etc. |
Hello, we have a huge application built locally and we had a similar crash when performing endurance test (no user interaction, just letting our app run for 2 hours): We have this crash if we change our build environment from VS2017 + Xamarin 9.1.7.0 to VS2019 + Xamarin 10.1.1.0. Is there a fix coming up? Note: we had the crash once, but didn't reproduce it on the next run with the same application. It feels like random so this gives us a pretty bad feeling about upgrading our dev environment. |
We had similar issues, all coming from We also disabled Startup Tracing because it did not improve the startup time for our Xamarin.Forms app, but made us feel less comfortable with the crashes. You could also try to use the The setting is enabled by default in VS 2019, that is why it took so long to find it. @jiro-san maybe that is why the crashes occur for you after changing the build environment. |
Concurrent garbage collector was already disabled for our test but I'll check the other things you suggest, it may be a good idea to change the GC bridge. |
We are unable to investigate this issue further without more information. Hopefully you found a resolution meanwhile! If not, please try the latest version of the product and if the problem still occurs, reply with the requested information and reopen this issue. |
I guess it has something to do with Packaging as .aab File and a new Version of VS/Xamarin/Mono.
It worked for our last release.
The Problem is happening with the newest Version of Visual Studio 2019 Preview as well.
Steps to Reproduce
Expected Behavior
No crash
Actual Behavior
Native crash with Fatal signal 6 (SIGABRT), code -6
Version Information
Log File
The text was updated successfully, but these errors were encountered: