LMDB fails to initialize due to`NtMapViewOfSection` returning `EAccess` error.

[Raikiri]

Compatibility Report

We're in the process of integrating LMDB (https://github.com/LMDB ) into our game and we're discovering that it fails to initialize under Proton.

System Information

• Proton version: tried on multiple proton versions, including 10.0 and Experimental

I confirm:

• that I haven't found an existing compatibility report for this game.
• that I have checked whether there are updates for my system available.

Symptoms

LMDB internally calls NtMapViewOfSection which is loaded directly from ntdll, but the call reports a permission denied error (EAccess). I'm not sure if it's a proton issue or a wine issue, but I'm not sure where to report wine issues, so I decided to report it here.

Reproduction

Try to open an LMDB environment with a call:

const auto error = mdb_env_open(env.get(), location.c_str(), MDB_NOMETASYNC, 0644)

Observe that it returns permission denied.

[Raikiri]

Is there a way to report a github user? This account is registered 11 hours ago and is trying to spread this malicious exe and there is no obvious way to report it.

[VoidCounsel]

The core problem with these NtMapViewOfSection failures is that Windows has a lazy memory accounting model (reserve now, commit later, charge only what you actually use) that Linux doesn’t have a direct equivalent for. Wine has to recreate that state machine on top of mmap, and when the reserve-vs-commit tracking or protection translation is off, you get exactly the access-denied errors LMDB and similar libraries hit.

There is real Windows logic for this. The Windows Research Kernel (XP/Server 2003) includes the actual MmMapViewOfSection code, and it shows the intended behavior clearly: SEC_RESERVE only reserves address space, commit charge is applied only to the portion that is actually committed, and the rest stays lazy until a fault or protect call brings it in. ReactOS has a useful re-implementation of the same ideas. So the reference behavior is not a mystery.

The practical path forward, imo, is to make Wine’s section objects track reserve vs commit state more accurately, translate those states into the correct Linux mappings, and log the exact flags + protection when a mapping is rejected. That combination, (better bookkeeping, WRK/ReactOS as a reference, and loud failures), is what will actually cover the LMDB cases and the next library that shows up with the same pattern.

[Raikiri]

Is there any ETA or timeline we can expect for this to be implemented? Currently we have to ship a separate implementation that kicks in whenever LMDB fails to initialize, but it's pretty nasty and we'd like to migrate entirely to LMDB.

Why is your reply hidden as "low quality"?