sdebruyn
commented
5 years ago Disabling LLVM makes the app work again... But I'm not a fan of disabling this
Closed sdebruyn closed 5 years ago
sdebruyn
commented
5 years ago Disabling LLVM makes the app work again... But I'm not a fan of disabling this
lexboss777
commented
5 years ago Have similar issues after upgrading. Waited for someone to create this issue.
[libc] Fatal signal 11 (SIGSEGV), code 1, fault addr 0x50 in tid 2487 (OkHttp Dispatch)
brendanzagaeski
commented
5 years ago Thanks for the report! The issue when LLVM is enabled is https://github.com/xamarin/xamarin-android/issues/2521. There's a fix landed upstream in Mono, but it isn't yet included in the published builds of Xamarin.Android. The fix adds an extra argument to the LLVM compilation step to avoid an incorrect optimization on the 32-bit armeabi-v7a architecture.
~A workaround in the mean time is to add the extra argument for LLVM explicitly to your .csproj file:~
<PropertyGroup> <AndroidAotAdditionalArguments>llvmopts="-data-layout=e-p:32:32-n32-S64 -O2 -disable-tail-calls"</AndroidAotAdditionalArguments> </PropertyGroup>
EDIT: The workaround of adjusting $(AndroidAotAdditionalArguments) is only valid if the project is targeting no architectures other than armeabi-v7a. See the later comment on this issue for more info.
@lexboss93, I believe the issue you are seeing is instead https://github.com/xamarin/xamarin-android/issues/2920. See that report for additional details on the status.
alexshikov
commented
5 years ago Unfortunately, the fix does not work for me. The app goes further but still crashes with a similar unclear crash.
brendanzagaeski
commented
5 years ago @alexshikov, if you can share additional details about the other crash you're seeing (such as the log from device similar to the original comment here, or a zipped up project that demonstrates the issue), please do submit a new issue with the information so I or another team member can investigate. Thanks in advance!
alexshikov
commented
5 years ago Thank for the fast response. I can't share the source code. But I find this piece of log pretty similar to the one above:
12c00000-13900000 rw-p 00000000 00:05 21344 /dev/ashmem/dalvik-main space (region space) (deleted)
13900000-14780000 rw-p 00d00000 00:05 21344 /dev/ashmem/dalvik-main space (region space) (deleted)
14780000-18280000 ---p 01b80000 00:05 21344 /dev/ashmem/dalvik-main space (region space) (deleted)
18280000-42c00000 rw-p 05680000 00:05 21344 /dev/ashmem/dalvik-main space (region space) (deleted)
6f816000-6fa4a000 rw-p 00000000 103:2d 122766 /data/dalvik-cache/arm/system@framework@boot.art
6fa4a000-6fa60000 r--p 00234000 103:2d 122766 /data/dalvik-cache/arm/system@framework@boot.art
6fa60000-6fb68000 rw-p 00000000 103:2d 122862 /data/dalvik-cache/arm/system@framework@boot-core-libart.art
6fb68000-6fb7a000 r--p 00108000 103:2d 122862 /data/dalvik-cache/arm/system@framework@boot-core-libart.art
6fb7a000-6fbad000 rw-p 00000000 103:2d 122984 /data/dalvik-cache/arm/system@framework@boot-conscrypt.art
6fbad000-6fbb0000 r--p 00033000 103:2d 122984 /data/dalvik-cache/arm/system@framework@boot-conscrypt.art
6fbb0000-6fbdf000 rw-p 00000000 103:2d 123043 /data/dalvik-cache/arm/system@framework@boot-okhttp.art
6fbdf000-6fbe2000 r--p 0002f000 103:2d 123043 /data/dalvik-cache/arm/system@framework@boot-okhttp.art
6fbe2000-6fc50000 rw-p 00000000 103:2d 123191 /data/dalvik-cache/arm/system@framework@boot-bouncycastle.art
6fc50000-6fc57000 r--p 0006e000 103:2d 123191 /data/dalvik-cache/arm/system@framework@boot-bouncycastle.art
6fc57000-6fcb2000 rw-p 00000000 103:2d 123332 /data/dalvik-cache/arm/system@framework@boot-apache-xml.art
6fcb2000-6fcb9000 r--p 0005b000 103:2d 123332 /data/dalvik-cache/arm/system@framework@boot-apache-xml.art
6fcb9000-6fcf4000 rw-p 00000000 103:2d 123558 /data/dalvik-cache/arm/system@framework@boot-ext.art
6fcf4000-6fcff000 r--p 0003b000 103:2d 123558 /data/dalvik-cache/arm/system@framework@boot-ext.art
6fcff000-70579000 rw-p 00000000 103:2d 124192 /data/dalvik-cache/arm/system@framework@boot-framework.art
...Let me know if the full log may help.
brendanzagaeski
commented
5 years ago @alexshikov, thanks! If we're lucky, the best additional clue will appear in the device log file (for example accessible using the adb logcat command). The extra clue that will hopefully be there is the backtrace from the crashing process, including both a Cause: line and a backtrace: line, similar to the log seen at the bottom of the original description for #2920. If by chance you're debugging the app, then the issue you're seeing might in fact be https://github.com/xamarin/xamarin-android/issues/2920 itself.
If the backtrace does not match the backtrace shown in https://github.com/xamarin/xamarin-android/issues/2920 or https://github.com/xamarin/xamarin-android/issues/2521, then please create a new issue and paste the backtrace there to help make it easy for any other users who might run across the same problem you're seeing to track the investigation. Thanks!
mfeingol
commented
5 years ago I'm running into the same startup crash problem after upgrading to VS 2019, which is fixed by disabling llvm. This was working fine with VS 2017.
I've attempted to use the llvmopts workaround mentioned above, but when release builds using that are deployed, I see the following errors:
4>XA3001: Could not AOT the assembly: HtmlAgilityPack.dll
4>XA3001: Could not AOT the assembly: Sideroads.Android.dll
4>XA3001: Could not AOT the assembly: Innovative.Geometry.Angle.dll
4>XA3001: Could not AOT the assembly: Geocoding.Google.dll
4>XA3001: Could not AOT the assembly: GeoTimeZone.dll
4>XA3001: Could not AOT the assembly: Geocoding.Core.dll
4>XA3001: Could not AOT the assembly: ImageCircle.Forms.Plugin.dll
4>XA3001: Could not AOT the assembly: FormsViewGroup.dll
4>XA3001: Could not AOT the assembly: Geo.dll
4>XA3001: Could not AOT the assembly: DocumentFormat.OpenXml.dllWhat can I provide to help diagnose this issue? Thanks.
brendanzagaeski
commented
5 years ago @mfeingol, you've probably already tried, but as one quick first idea, there's a chance that running Build > Clean on the project or deleting the obj directory might help with the "Could not AOT the assembly" errors. If not, a good next step would be to check the diagnostic MSBuild output for additional information about how the AOT step failed. If that additional information doesn't make it clear how to resolve the problem, I'd recommend to attach the diagnostic build output on a new issue, and I or another member of the team can take a look. Thanks!
Steps to collect diagnostic build output (on Windows):
mfeingol
commented
5 years ago Okay, thanks, Brendan. I feel silly. Deleting bin/obj helped get the deployment working, and the AndroidAotAdditionalArguments workaround fixed the startup crash. And hopefully we'll see a proper fix for https://github.com/xamarin/xamarin-android/issues/2521 soon.
brendanzagaeski
commented
5 years ago Ah, good. Glad to hear that helped! And no worries. I think there are some scenarios around llvmopts that will need to be fixed up in the build logic so that manual cleanup of the output files won't be necessary when those options change. When I get a chance, I'll aim to experiment with those scenarios and file an issue about them.
brendanzagaeski
commented
5 years ago Important invalidation of the workaround: As another user and I were looking at this same problem on https://github.com/xamarin/xamarin-android/issues/2966, we discovered something I should have realized sooner. The workaround of adjusting $(AndroidAotAdditionalArguments) is only valid if the project is targeting no architectures other than armeabi-v7a. It is important not to have those adjustments applied to the arm64-v8a architecture. Otherwise the original crash symptoms will happen again, but this time on the 64-bit architecture.
I did a bit of follow-up testing around this, and it looks like it is technically still possible to work around the issue by customizing the whole _BuildApkEmbed target (see https://github.com/xamarin/xamarin-android/issues/2966#issuecomment-484281295 for details), but where possible, it's likely best to wait for a servicing update that includes the upstream fix from Mono instead.
mfeingol
commented
5 years ago Any sense of which VS version will include the fix?
brendanzagaeski
commented
5 years ago In case anyone might want to test out a preview version that includes the fix, Visual Studio 2019 version 16.1 Preview 2 that was published today includes Xamarin.Android SDK version 9.3.0.14, which has the fix. I did a quick first check using that version without any other workarounds, and I got the expected behavior.
Barring unexpected complications, the corresponding preview version of the Xamarin.Android SDK in Visual Studio for Mac should be available a little later this week too.
davidevosti
commented
5 years ago This bug seems to happen again when using Xamarin.Android 10 and with Profiled AOT enabled. By downgrading to Xamarin.Android 9.4.1.0 the app won't crash
iamlawrencev
commented
5 years ago @davidevosti happens to me as well on Android 10 SDK. Unfortunately I cannot downgrade as to work on Android's dark mode.
brendanzagaeski
commented
5 years ago @davidevosti, @iamlawrencev, thanks for the information! If either of you could submit a new issue that describes what you're seeing so the team can take a look, that would be perfect. Thanks for your patience!
davidevosti
commented
5 years ago Hi Brendan.
I'll do it, I just need some time to restore that environment. I'll put the link once I've done that.
Cheers
On Wed, Oct 9, 2019 at 6:04 AM Brendan Zagaeski notifications@github.com wrote:
@davidevosti https://github.com/davidevosti, @iamlawrencev https://github.com/iamlawrencev, thanks for the information! If either of you could submit a new issue that describes what you're seeing so the team can take a look, that would be perfect. Thanks for your patience!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xamarin/xamarin-android/issues/2960?email_source=notifications&email_token=AAATHB2CM65PEX4Z5PCMSATQNVJ4DA5CNFSM4HFFHPFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAWPGKY#issuecomment-539816747, or mute the thread https://github.com/notifications/unsubscribe-auth/AAATHB3WMQN45HZIS7KPQX3QNVJ4DANCNFSM4HFFHPFA .
davidevosti
commented
4 years ago It seems that as of Xamarin.Android 10.0.3.0 it is fixed again.
Steps to Reproduce
Expected Behavior
App works :)
Actual Behavior
App crashes :(
Build settings
NuGet packages
Version Information
https://github.com/bitrise-io/bitrise.io/blob/master/system_reports/osx-vs4mac-stable.log
Log File