Massive Problems with random crashes (SIGSEGV and SIGABRT) #21479
Comments
|
Can you attach a binlog? A repro would also be helpful |
PureWeen
added
platform/android 🤖
s/needs-info
|
This is the full logcat. Since then I activated additional Mono logging. I'll try to reproduce it, but it will take several hours to make it happen again. I am unable to provide a repro. I had no success reproducing the error in a repro app. |
dotnet-policy-service
bot
added
s/needs-attention
|
Have you looked through the logcat yourself? Do you see anything that makes sense? While we can glance over it we might miss something since we don't know anything about your app and know what might be relevant or not |
|
I went through the log in detail and am not able to find any reason for the error to be caused by my code. I am aware that I am causing it indirectly. From the crash report I can see that the crash happens in the Mono Garbage Collector process (SGen worker). How would I be able to cause such a crash from a MAUI app? From my understanding this should not be possible. Please correct me if I'm wrong. I even added a lot of logging and commeted sections of code to find a possible location where this happens. But for now it seems absolutely random. |
|
@jfversluis I am also facing similar crash, on play store this is contributing to 2% crash rate of my app. I tried reading through the entire logcat file, but nothing I am able to figure out. Plz assist. |
|
I'm having the same problem, updated from 8.0.7 to 8.0.21 and started getting SIGSEGVs. I downgraded back to 8.0.7 and that seems to have stopped the crashes. When I was on 8.0.21, I started using Sentry and that made the crashes even worse. Removing Sentry made it less severe, but it wasn't until I downgraded the the issue went away completely. |
|
I found the more I/O happens, the more likely it is to crash. I was able to reduce the amount of crashes by limiting the data written and read from storage. It is better, but it still happens. And it is no permanent solution. In my case it happens in earlier versions, like the 8.0.7, too. |
|
@ac-lap @pijnappel In your apps could this be related to accessing already disposed objects? |
|
Hi, We are getting this too - it kills our app whilst it's backgrounding; No ideas how to fight this one as there is no stack trace into our .NET code, and it sounds too low level. I have the full Android bug report file I can supply if it would be helpful. This is a release build installed from Google Play. |
|
This really needs to be addressed! We are still struggling with theses crashes. No chance to reproduce or trace the problem and no support. Can someone please give instructions on debugging or isolating the problem? Is it possible to get information about these errors from the garbage collector? |
|
I think this sort of thing risks flying under the radar as for a lot of apps this issue will result in a crash which manifests as the app disappearing in front of the user, after which the user will roll their eyes before simply restarting the app and continuing to use it. You might risk a few poor reviews but generally the app will function. However, the moment you get into backgrounding things get worse as the user isn't there to work around the problem for you. Your app is killed and just never comes back, the user might not know for days until they see some other side effect such as something not updating on a web portal. A good analogy would be that you're trying to write a Windows service but due to the platform/toolchain/APIs/whatever your program could simply terminate at any moment without warning. We're going to work around this by employing countermeasures such as popping up an "emergency" push notification asking the user to tap to re-open the app if things stop functioning but it is not at all ideal. |
|
I also see this in the latest MAUI version 8.0.81 in Sentry dashboard |
which version is that? |
Ooops, I mean 8.0.80 😵💫 |
|
Hi, we are experiencing this as well on our MAUI app using the newest MAUI version. Most of the time it is something like where the name can also be .NET TP Worker with a different fault address. What causes the Null Pointer Deference? Where is it caused? We do not know.... and there is no hint or clue for finding a solution. It is like fishing in muddy waters, very frustrating. We catch every single exception that is happening in our code, so we are save from that side, but when a native exception occurs we are completely helpless. The app just closes without any useful hint. We also tried to use ndk-stack for more information, but no chance. |
|
I don't think its an issue with our code - I think it's an internal issue with the runtime. At best we can possibly try to avoid it if some pattern is more likely to cause it, but I don't think it will end up being a bug in our respective code we can "fix" as such. That's sort of the problem as developers can't fix it themselves and what tends to happen is the MS developers working at the level with the problem (e.g. the runtime) seem to lack examples of apps of moderate to high complexity which would cause this problem to trigger so they ask the community for "base-case" simple examples which are extremely hard to create as often simple "hello world" apps don't have the issue and/or there is a temporal component (e.g. the crash happens once a day/week/whatever). If MS had more apps using MAUI they would likely naturally have those examples to hand and be seeing these issues in the field - this is probably how APIs such as the Windows API itself became so battle hardened in comparison to these "Web 2.0 nu-APIs" where there is a much fatter layer of chaos and undefined behaviour which appears to linger a lot longer. |
|
We found a workaround. The chrashes vanish if we deactivate concurrent garbage collection in the project settings.
I am not sure about the side effects and impacts on performance. When running calculation processes, we see random pauses of the execution for 300ms or more. I assume this happens when the GC is triggered. I haven't found a way to pause the GC for the duration of our calculations. |
|
Android : AOT Off, Startup Tracing Off, Garbage Collection Off, Enable Trimming Off |
Android : AOT Off, Startup Tracing Off, Garbage Collection Off, Enable Trimming Off |
|
Suffering from this as well. Initially I thought it could be my fault after looking at my logs, but I have since added additional logging and think it must be something with the framework. In my case it happens at app startup and like others I have trouble reproducing it! It began happening after I updated from MAUI controls 8.0.6 to 8.0.80 and the .net Android framework to the latest version. |
|
Just to update that it seems that disabling the concurrent garbage collector together with enabling AOT fixed my issue as well. |
|
This is definitely not a Maui issue, it’s a runtime issue. Thanks for tagging my own issue above which appears to be the same as this. For us the issue started when we “upgraded” from the older xamarin framework to .net. |
|
I have a segfault too but I've not explicitly enabled AndroidEnableSGenConcurrent so I don't think it's related since the default is false. Mine appears to be network / connectivity related (see #25446) and I only mention it in case it's relevant here for others. |
|
In .net android the default is True. In Xamarin.Android the default was false. |
I think you mean in .net-android the default is true? MAUI has nothing to do with it. |
|
Yes, I meant .net android. |
jaosnz-rep
added
s/triaged
|
Looks like another discussion is happening here which is probably the more appropriate place seeing that this is not something that .NET MAUI influences directly. Closing this one here. |
Description
We are still experiencing random crashes of our app. I've been trying for month to debug and locate them. Its increasingly frustrating because there is no possibility to locate the origin of these errors.
03-27 09:19:59.028 4846 4860 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2c0030002c0039 in tid 4860 (SGen worker), pid 4846 (ctro.mobile.xrf)Most of the time I see 'SGen worker' in the message, sometimes it is '.NET TP Worker'. I am always running in release mode when this happens, was not able to reproduce this in DEBUG.
Steps to Reproduce
The app is very complex and it is not possible to reproduce these crashes in a minimal repro app. I am running an automation service in a foreground service which performs measurements and calculations using custom hardware components (serial communication). A client (in this case the same android device) triggers a measurement process. The process runs in a separate task, creates result data and stores it to the device memory (in memory json serialization, writing bytes to the file), then adds it to an index (Lucene.Net). On the UI side status events are observed and progress and result information is shown.
Most of the time the process runs flawlessly. Then suddenly the app crashes (All global exception handling is ignored). I tried locating the line of code where the crash happens (with traces), but I could only locate that it is most likely happening in the processing, not in UI.
Link to public reproduction project repository
No response
Version with bug
8.0.10 SR3
Is this a regression from previous behavior?
Not sure, did not test other versions
Last version that worked well
Unknown/Other
Affected platforms
Android
Affected platform versions
Android 9
Did you find any workaround?
I switched several processes (saving files, indexing) from running in separate threads to running synchronously. I thought this resolved the problem. But now it happened again.
Relevant log output
The text was updated successfully, but these errors were encountered: