Random SIGSEGVs after porting from Xamarin to net8-android #98933
Comments
ghost
added
the
|
Tagging subscribers to 'arch-android': @steveisok, @akoeplinger Issue DetailsDescriptionThe last major release of our software followed our porting of the software from Xamarin.Android to net8.0-android. Everything appeared to go well in our own tests, but we are getting a lot of reports of crashes out in the wild. We have been unable to reproduce any problem in our office, but with tens of thousands of customers using the software every day, this crashing is a major problem for us. We've been receiving no managed crash reports via our own telemetry, so we suspected this was a runtime issue. Finally a tech-savvy customer has sent us some debug output, which I'll paste below. We also have some sample stack traces from the Play Store telemetry which I will also paste below. What I urgently need is for someone knowledgeable on runtime issues to advise if there's a component clearly at fault that we can temporarily turn off or avoid, so we can get back to having a stable app. I could roll back to Xamarin.Android but that is not sustainable long term. Reproduction StepsWe cannot reproduce this issue ourselves. Expected behaviorNo crash Actual behaviorSome crash output below.
`*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** backtrace: `*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** backtrace: Regression?Definite regression from Xamarin.Android to net8.0-android Known WorkaroundsNo response ConfigurationWe have noticed nothing in common between the devices this is happening on, nor the Android versions being used. Other informationNo response
|
|
@divil5000 Was your app built with .NET 8.0.0 or .NET 8.0.1? There was a regression that was only fixed in .NET8.0.2 #96872 Do you have complete ADB logs of the crashes? Could you check if there are any "assertion failed" messages in the logs? |
|
It doesn't look like #96872. There's a couple of separate problems here:
|
|
It looks like I've got 8.0.101 installed on the machine used to produce the software. I don't have complete ADB logs. I do have quite a comprehensive log sent by the customer, but I am not familiar with the format. Some of it seems to be normal log output, and it's where I got a couple of my stack traces from above. I've searched the whole thing, and there is no instance of "assertion failed". |
|
More further crash information received overnight from one customer. I have a more comprehensive log output from them but can't upload it here. I'm happy to send it zipped to somewhere secure for Microsoft to reference it though, in case its contents (which is far more than I have pasted here) are helpful. |
|
Cc @vitek-karas |
|
@divil5000 please open an issue on Developer Community https://developercommunity.microsoft.com/dotnet/report and attach the full logs there, the send us the link here. I think that we will likely also need a copy of your .apk to try to reproduce the issue |
|
I reviewed the provided logs (in this issue and in the Develper Community toolkit) and there isn't enough information to identify where the null pointer dereference occurred. We would need some actionable information to address this issue (repro app, symbilicated backtrace). @divil5000 I'm closing this issue now. If you have more information you could share, please reopen this issue or open a new one and we will look into it. |
dotnet-policy-service
bot
removed
the
untriaged
Description
The last major release of our software followed our porting of the software from Xamarin.Android to net8.0-android. Everything appeared to go well in our own tests, but we are getting a lot of reports of crashes out in the wild. We have been unable to reproduce any problem in our office, but with tens of thousands of customers using the software every day, this crashing is a major problem for us.
We've been receiving no managed crash reports via our own telemetry, so we suspected this was a runtime issue. Finally a tech-savvy customer has sent us some debug output, which I'll paste below. We also have some sample stack traces from the Play Store telemetry which I will also paste below.
What I urgently need is for someone knowledgeable on runtime issues to advise if there's a component clearly at fault that we can temporarily turn off or avoid, so we can get back to having a stable app. I could roll back to Xamarin.Android but that is not sustainable long term.
Reproduction Steps
We cannot reproduce this issue ourselves.
Expected behavior
No crash
Actual behavior
Some crash output below.
Regression?
Definite regression from Xamarin.Android to net8.0-android
Known Workarounds
No response
Configuration
We have noticed nothing in common between the devices this is happening on, nor the Android versions being used.
Other information
No response
The text was updated successfully, but these errors were encountered: