qarth::QarthPatchMonintor::CheckNotifyEvent

[sleushunou]

Android framework version

net9.0-android

Affected platform version

.NET 9.06

Description

I see a group of errors in Sentry, which is very difficult to understand what is falling.

example of stacktraces:

1. OS Version: Android 15 (AP3A.240905.015.A2.S901EXXSCFYF1)
   Report Version: 104

Exception Type: Unknown (SIGSEGV)

Application Specific Information:
Segfault

Thread 0 Crashed:
0 libaot-Gambino.Features.dll.so 0x6c87c11d84 + 466134048132

EOF

2. OS Version: Android 11 (RPRS31.Q1-56-9-15)
   Report Version: 104

Exception Type: Unknown (SIGSEGV)

Application Specific Information:
Segfault

Thread 0 Crashed:
0 0xd064ded8

EOF

for some reason, title in Sentry of this crash is "qarth::QarthPatchMonintor::CheckNotifyEvent", but there are no info about qarth in stacktrace

Steps to Reproduce

no steps

Did you find any workaround?

no

Relevant log output

[jonathanpeppers]

Can you get a more in-depth log?

Try doing:

# enable more logging
adb shell setprop debug.mono.log default,assembly,mono_log_level=debug,mono_log_mask=all
# clear log
adb logcat -c
# launch the app, make it crash
# save the log
adb logcat -d > log.txt

See: https://learn.microsoft.com/previous-versions/xamarin/android/troubleshooting/troubleshooting#android-debug-log-output

Then share log.txt here, thanks!

[sleushunou]

I haven't found any ways to reproduce it yet. From the logs it's only clear that it happens at the start of the application. is there a way to make the stacktrace in sentry more informative?

[sleushunou]

Seems like this exception occurs it (founded in adb logs)
It's not very clear what the problem could be here

android.database.CursorWindowAllocationException: Could not allocate CursorWindow '/data/user/0/gambino.android/no_backup/androidx.work.workdb' of size 2097152 due to error -13.
at android.database.CursorWindow.nativeCreate(CursorWindow.java)
at android.database.CursorWindow.(CursorWindow.java:139)
at android.database.CursorWindow.(CursorWindow.java:120)
at android.database.AbstractWindowedCursor.clearOrCreateWindow(AbstractWindowedCursor.java:202)
at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:147)
at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:140)
at android.database.AbstractCursor.moveToPosition(AbstractCursor.java:231)
at android.database.AbstractCursor.moveToNext(AbstractCursor.java:280)
at androidx.room.InvalidationTracker$1.checkUpdatedTable(InvalidationTracker.java:463)
at androidx.room.InvalidationTracker$1.run(InvalidationTracker.java:433)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:923)

[jonathanpeppers]

I like what Copilot suggested about this:

This Android error indicates a permission denied issue when trying to allocate memory for a SQLite database cursor window.

• CursorWindowAllocationException: Android couldn't create a memory buffer (cursor window) to read database results
• Size: 2097152 bytes (2MB) - this is the default cursor window size
• Error -13: This is EACCES (Permission Denied) in Unix/Linux error codes

Common Causes

Storage Space Issues:

• Device is out of internal storage space
• Insufficient memory available for the operation

Database File Permissions:

• The database file /data/user/0/gambino.android/no_backup/androidx.work.workdb has incorrect permissions
• The app doesn't have write access to its own private directory (unusual but possible)

Memory Constraints:

• System is low on RAM
• The app has hit memory limits imposed by the system

Database Corruption:

• The WorkManager database file is corrupted

What I would suggest

If this is a rare issue, only seen on a crash report for a tiny % of users. I would just consider that they actually are out of disk space.

If it's happening frequently, I'd look into seeing if you can handle the error gracefully. Or see if there are places you can use LIMIT in your query.

[sleushunou]

It's not rare issue :(
"Or see if there are places you can use LIMIT in your query". - I don't use this database inside my code, seems like it's androidx worker database

[jonathanpeppers]

This is just what Copilot suggested:

// This will reset WorkManager's internal database
WorkManager.GetInstance(context).CancelAllWork();

// Handle exception gracefully
try 
{
    // Your database operation
}
catch (Android.Database.CursorWindowAllocationException ex)
{
    // Log the error and implement fallback logic
    Log.Error("DB", "Cursor allocation failed", ex);
    // Potentially restart WorkManager or clear its database
}

I would look for other examples in Java/Kotlin where people had the same issue. It's all happening on the Java/Kotlin side, so I don't think there is an issue in dotnet/android here.

[sleushunou]

seems line promlem is caused by OneSignal SDK dotnet library (5.2.1)
issue: OneSignal/OneSignal-DotNet-SDK#142