SetEndOfFile() failed: The requested operation cannot be performed on a file with a user-mapped section open.

[raudabaugh]

Goals

We have a ASP.NET Core GraphQL server that is built on top of Realm .NET SDK and are having occasional stability issues when trying to open a synchronized Realm.

Expected Results

Execute Realm.GetInstance(config) consistently without error.

Actual Results

Some time after the GraphQL server has started and an indeterminate amount of user activity, every call to Realm.GetInstance(config) throws this error:

Sep 29 10:53:29 52.170.18.62 ThreadAPI: ERROR - SetEndOfFile() failed: The requested operation cannot be performed on a file with a user-mapped section open.
Sep 29 10:53:29 52.170.18.62 ThreadAPI: GraphQL.ExecutionError: SetEndOfFile() failed: The requested operation cannot be performed on a file with a user-mapped section open. ---> GraphQL.Conventions.Execution.FieldResolutionException: SetEndOfFile() failed: The requested operation cannot be performed on a file with a user-mapped section open. ---> Realms.Exceptions.RealmException: SetEndOfFile() failed: The requested operation cannot be performed on a file with a user-mapped section open.
Sep 29 10:53:29 52.170.18.62 ThreadAPI:    at Realms.NativeException.ThrowIfNecessary(Func`2 overrider)
Sep 29 10:53:29 52.170.18.62 ThreadAPI:    at Realms.Sync.SharedRealmHandleExtensions.OpenWithSync(Configuration configuration, SyncConfiguration syncConfiguration, RealmSchema schema, Byte[] encryptionKey)
Sep 29 10:53:29 52.170.18.62 ThreadAPI:    at Realms.Sync.SyncConfigurationBase.CreateRealm(RealmSchema schema)
Sep 29 10:53:29 52.170.18.62 ThreadAPI:    at Thread.DomainData.RealmFactory.Open(String orgId, String studentId, SyncArchitecture architecture, String syncHost) in D:\a\1\s\DomainData\RealmFactory.cs:line 254The only way for us to get it out of this state is to restart the GraphQL server entirely.

Version of Realm and Tooling

• Realm Object Server Version: 3.25.5
• Flavor:
  • [x] Realm Cloud
  • [ ] Self-Hosted
• Client SDK Version: 4.1.0
• Client OS & Version: Azure App Service on Windows (Microsoft Windows NT 10.0.14393.0)

[buchenberg]

@raudabaugh

I was having the very same issue while developing and testing the Hangfire.Realm extension. In my case, I was using two different Realm configurations. I was storing some objects in a separate Realm file as in the following.

RealmConfiguration fooConfig = new RealmConfiguration(fooFilePath) { ObjectClasses = new Type[] { typeof(FooDto), } }; RealmConfiguration barConfig = new RealmConfiguration(barFilePath) { ObjectClasses = new Type[] { typeof(BarDto), } };

The error was occurring intermittently during various operations when Realm.GetInstance(config) was called.

I was able to eliminate the error entirely by consolidating my Realm data to a single configuration instance. I know this doesn't really match your case but perhaps will add some insight. In your case you might try running your GraphQL server on Linux if you can. My assumption (untested) is that this error would not exist outside of a Windows environment.

[nirinchev]

That is correct - our current hypothesis is that something in our process lock machinery is wrong on Windows.

[buchenberg]

@nirinchev

It seems I was not able to eliminate the issue on Windows entirely by using a single Realm file. I'm getting the error intermittently even with a single Realm file. I would love to help solve this issue. Do you have any other information on the issue that I and others can be aware of? Also, I assume this issue is actually with realm-core. Correct?

[nirinchev]

@finnschiermer will this go away with Core 6? If it will, I guess the best we can do is tell people to wait until that ships?

[buchenberg]

@nirinchev @finnschiermer

I was able to isolate what was causing my remaining SetEndOfFile() error. Any time an exception was thrown in my application I was getting the error on any following Realm operations. The issue only occurs when I am running a debugger. When the application is running without a debugger attached the SetEndOfFile() error disappears.

[VagueGit]

We get this issue for our app from time to time in the Microsoft App Center.

Realms.Exceptions.RealmException: SetEndOfFile() failed: The requested operation cannot be performed on a file with a user-mapped section open.

It is quite rare. I post a stack trace to add grist to the mill

Realms.Sync SharedRealmHandleExtensions.OpenWithSync ($Configuration configuration, $SyncConfiguration syncConfiguration, $RealmSchema schema, Byte[] encryptionKey) at 0 Realms.Sync SyncConfigurationBase.CreateRealm ($RealmSchema schema) at 0 Realms Realm.GetInstance ($RealmConfigurationBase config, $RealmSchema schema) at 0 Realms Realm.GetInstance ($RealmConfigurationBase config) at 0 Wibble.Services DataService.GetRealm () at 0

GetRealm looks like this

public static Realm GetRealm()
{
    try
    {
        FullSyncConfiguration config = new FullSyncConfiguration(dataURI, realmUser);
        config.EnableSSLValidation = false;
        Realm realm = Realm.GetInstance(config);
        return realm;
    }
    catch (IncompatibleSyncedFileException)
    {
        throw;
    }
}

The user action in this case is a core business process, so occurs maybe 3,000 times per day, but we only see

Realms.Exceptions.RealmException: SetEndOfFile() failed

about once a week or less. In some cases the user is unable to restart our app, getting the same error on startup.

[VagueGit]

We're seeing this issue fairly frequently now with one customer. But now we are seeing a weird stack trace:

SharedRealmHandleExtensions.OpenWithSync ($Configuration configuration, $SyncConfiguration syncConfiguration,
$RealmSchema schema, Byte[] encryptionKey) C:\jenkins\workspace\realm_realm\Realm\Realm\Handles\SharedRealmHandleExtensions.cs at 166:13
Realms.Sync
SyncConfigurationBase.CreateRealm ($RealmSchema schema) C:\jenkins\workspace\realm_realm\Realm\Realm\Configurations\SyncConfigurationBase.cs at 221:13
Realms
Realm.GetInstance ($RealmConfigurationBase config, $RealmSchema schema) C:\jenkins\workspace\realm_realm\Realm\Realm\Realm.cs at 137:13

This is the first time I have seen this in jenkins/workspace. Ours is a UWP app installed from the Micro$ Store. Why are we seeing realm in C:\jenkins\workspace?

[nirinchev]

These lines indicate where the Realm library was built (it's getting built on Jenkins), so it's expected.

Can you reproduce the issue locally or does it happen only on the customer's device?

[VagueGit]

We haven't been able to reproduce

[nirinchev]

Do you have any other information that may help us narrow down the source? E.g. how large is the database, what version of Windows they're running, are they using any peculiar locale?

[VagueGit]

Very small database WINDOWS 10.0.19041 locale en-GB

I have the raw dump from the app center. How can I share that with you in confidence?

[nirinchev]

You can send it on my email - [email protected] and I'll try to find someone on the core team who can take a look at it.

[ali-h2010]

I am facing a similar issue in UWP. var realm = Realm.GetInstance();

is giving me this exception:

  at Realms.NativeException.ThrowIfNecessary(Func`2 overrider)
   at Realms.SharedRealmHandle.Open(Configuration configuration, RealmSchema schema, Byte[] encryptionKey)
   at Realms.RealmConfiguration.CreateRealm(RealmSchema schema)
   at UwpClient.App.AddNotificationToRealmDB(EmployeeNotification ReceivedNotification) 

i am using using:

realm.Write(() =>
                    {
                       //add to realm
                    });

and to delete the items i use: using (var transaction = realm.BeginWrite()) { realm.RemoveRange(...) transaction.Commit(); }

This issue appeared when i updated my schema even though i cleaned the whole DB and updated the schema version.

[ali-h2010]

I replaced all my writes with writeAsync and it seems that the exception is not showing for now. i am not sure if i can consider it resolved though

await realm.WriteAsync(tempRealm => { tempRealm.Add(item); });

[ali-h2010]

It seems that issue returned randomly

[sync-by-unito[bot]]

➤ nirinchev commented:

We believe this has been fixed with recent changes to the Core database.