Pixel on Android 14+ hardlocks when getting instance in /storage/emulated/0/Android/data/<appname>/files

[Joehuu]

What happened?

Hello, I'm a regular contributor in osu! and we haven't updated since 11.5.0. Paper trail here: ppy/osu#27920

This issue mentioned in the title is happening since https://github.com/realm/realm-dotnet/releases/tag/11.6.1. I have a Pixel 6a on Android 14, but this may affect any Pixel on Android 14. I am emphasizing Pixel because an osu! dev doesn't experience such an issue on a non-pixel on Android 14: ppy/osu#27920 (comment).

Also throwing in phones from users experiencing the issue the last time we bumped Realm >=11.6.1 to production: Xperia 1 V and AQUOS R8 pro. Those phones are capable of running Android 14. Ref: ppy/osu#27738

Repro steps

The below is similar to what I think osu! does in it's getConfiguration(): https://github.com/ppy/osu/blob/565107205c60f14488f1642011808d286d712c31/osu.Game/Database/RealmAccess.cs#L745 (namely storage.GetFullPath(filename ?? Filename, true)). If you want to test osu! side, remove that storage.GetFullPath() and it should run. Revert and it'll get stuck.

Apply this diff and run. It should get stuck at this line:

realm = Realm.GetInstance(@"/storage/emulated/0/Android/data/com.companyname.quickjournal/files/client.realm");

diff --git a/examples/QuickJournal/QuickJournal.csproj b/examples/QuickJournal/QuickJournal.csproj
index a3e4d124..f3c930b8 100644
--- a/examples/QuickJournal/QuickJournal.csproj
+++ b/examples/QuickJournal/QuickJournal.csproj
@@ -44,7 +44,7 @@
 		<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="7.0.0" />
 		<PackageReference Include="CommunityToolkit.Maui" Version="5.2.0" />
 		<PackageReference Include="CommunityToolkit.Mvvm" Version="8.2.1" />
-		<PackageReference Include="Realm" Version="11.3.0" />
+		<PackageReference Include="Realm" Version="12.3.0" />
 		<PackageReference Include="StyleCop.Analyzers" Version="1.1.118">
 		  <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
 		  <PrivateAssets>all</PrivateAssets>
diff --git a/examples/QuickJournal/ViewModels/EntriesViewModel.cs b/examples/QuickJournal/ViewModels/EntriesViewModel.cs
index a57f41e9..52a3a31e 100644
--- a/examples/QuickJournal/ViewModels/EntriesViewModel.cs
+++ b/examples/QuickJournal/ViewModels/EntriesViewModel.cs
@@ -17,7 +17,8 @@ public partial class EntriesViewModel : ObservableObject
 
         public EntriesViewModel()
         {
-            realm = Realm.GetInstance();
+            Directory.CreateDirectory(@"/storage/emulated/0/Android/data/com.companyname.quickjournal/files");
+            realm = Realm.GetInstance(@"/storage/emulated/0/Android/data/com.companyname.quickjournal/files/client.realm");
             Entries = realm.All<JournalEntry>();
 
             // We are using a WeakReferenceManager here to get notified when JournalEntriesDetailPage is closed.
@@ -78,4 +79,4 @@ private async void EntryModifiedHandler(object recipient, EntryModifiedMessage m
             }
         }
     }
-}
\ No newline at end of file
+}

Version

8.0

What Atlas Services are you using?

Local Database only

What type of application is this?

Other

Client OS and version

Android 14 (Pixels), since https://github.com/realm/realm-dotnet/releases/tag/11.6.1

Code snippets

No response

Stacktrace of the exception/crash you're getting

No response

Relevant log output

No response

[sync-by-unito]

➤ PM Bot commented:

Jira ticket: RCORE-2226

[jedelbo]

@nirinchev what can we do to make progress here?

[Joehuu]

Not them, but I did some bisecting and unconventional building using GitHub Actions at https://github.com/realm/realm-dotnet. The problem seemingly originates in e003bda.

Note that I don't have a clue what the code does.

Edit: I could reproduce the problem in the latest Android 15 emulator, if you don't have a physical device.

[bdach]

Given the uncertainty regarding the future of realm at large (see realm/realm-dotnet#3676) I've decided to spend a few more hours investigating this myself off the top of the investigation above. I'm not very well versed in cpp or cmake (or even willing to be, to be quite honest), so I used quite crude techniques.

Knowing that e003bda appears to be responsible for this, and seeing that that commit introduced new three cmake feature detection toggles, I decided to produce 3 versions of realm-core with the appropriate toggles nudged and see if I can isolate the one that breaks things. And the one that appears to be the source of breakage here is REALM_HAVE_POSIX_FALLOCATE; with that feature toggle crudely turned off for android, the sample app appears to open fine even with absolute directory app specified as per the patch in the OP.

Notably, on source inspection, the modified #ifdef is followed by this:

realm-core/src/realm/util/file.cpp

Lines 955 to 957 in 978ca22

	#elif REALM_ANDROID || defined(_WIN32) || defined(__EMSCRIPTEN__)
	manually_consume_space();
	#else

which is an ifdef path that appears to be explicitly intended for android, but now will presumably not taken as posix_fallocate() is indeed going to be available on android. I tried looking in blame for any clues as to why this code path might have been added, but no dice - the code seems to originate at #2973 and there's seemingly no real explanation or discussion as to why android is taking a different path that skips posix_fallocate().

I'm not sure why posix_fallocate() seemingly deadlocks in this situation either; it doesn't appear to do so in a blank android app I tested, so this might have to do something with the particular usage pattern. I'm not sure how I'd be able to get more instrumentation here, since I have no idea how I'd log anything from within File on the realm side, and I haven't even been able to figure out as much as how to run strace on android to approach it from that side due to everything being locked down.

[jedelbo]

@fealebenpae any chance that you could have a look at this?

[charlesroddie]

The need to add Alpine compilation (#7372) wasn't stated. Now that Realm is slimming down, perhaps this support can be removed now by reverting the original PR and subsequent fixes?

[fealebenpae]

We run the .NET unit tests on a Pixel 8 device running Android 14 over at AWS Device Farm and we haven't seen issues there, so there must be something very subjective that triggers this. Unfortunately I don't have the capacity to investigate so I think the safest best is to just explicitly opt-out of posix_fallocate on Android. Ideally we want to use posix_fallocate since it's more performant and Android's bionic does implement it, but we don't have the resources to investigate yet another gem of Android's emulated storage.

We can't revert the musl support because IIRC we had customers wanting to run an SDK on a musl-based IoT device.

[nirinchev]

If no one experiencing the issue is using sync, we could theoretically revert that PR changes onto the local only branch as it's unlikely anyone depends on musl c for the offline database.

[peppy]

Sorry to be a pain, but given that you guys are keeping realm updated with compatibility fixes elsewhere (thanks for this), it would be amazing if a potential revert of the breaking changes here could be considered so that we can track the latest release for our projects.

I don't know the full context but based on @nirinchev's last reply, it seems like it may be a very quick no-brainer change based on Sync being put to sleep.

[jedelbo]

RealmCore v20.1.2 on the community branch hopefully solves this.