mORMot Open Source

vs

Member

Registered: 2019-10-21

Posts: 69

_GetSystemEnv: nil slot in cache -> AV in FindNonVoidRawUtf8I

Hi Arnaud,

Saw the _GetSystemEnv() churn — 060a7369 then today's revert df820de — so I'll raise a long-standing intermittent AV I have in exactly that code.

_GetSystemEnv occasionally leaves a single nil hole in _SystemEnvNames[] (preflight count n vs fill index i out of sync by one).
Later GetSystemEnv('HTTP_PROXY') from an outbound TSimpleHttpClient hits it in FindNonVoidRawUtf8I → AV on the nil p1, breaking its all VName[]<>'' precondition.
Caught by our handler, but spams the log on cold starts.

Captured 6× with a guard that returns -1 instead of crashing:

nil at idx 23/38 name="HTTP_PROXY"
samples=[EFC_12084_2775293581 | FPS_BROWSER_APP_PROFILE_STRING | ALLUSERSPROFILE]

The nil index shifts run-to-run (23, 46, 22, 43…), tracking one odd env entry (this box has injected EFC_*/OneDrive names; a clean server likely never hits it).
Was the recent change aimed at this same desync?
Happy to share the guard + all captures and test any patch.

Win11 26200, FPC 3.2.3 x86_64. Thanks!

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 15,554

Website

Re: _GetSystemEnv: nil slot in cache -> AV in FindNonVoidRawUtf8I

Hello Valerii,

After https://github.com/synopse/mORMot2/commit/df820de it should not happen any more, since it reverted https://github.com/synopse/mORMot2/commit/060a7369d
With the current trunk, p - e > 0 so _SystemEnvNames[] should never be nil.

Or did I miss something?

Also ensure you did rebuild your mormot package.

Edit:
I have rewritten the function to be safer:
https://github.com/synopse/mORMot2/commit/822aa0ab3

vs

Member

Registered: 2019-10-21

Posts: 69

Re: _GetSystemEnv: nil slot in cache -> AV in FindNonVoidRawUtf8I

Update — I tested this deterministically by feeding a hand-crafted env block to both the old scan and your 822aa0a version:

- an env entry with no = in it: the old scan runs past the missing =, so one name ends up empty (the nil slot); 822aa0a handles it — no empty name.
- a name with a broken UTF-16 char: both versions still produce a valid name, so Unicode_ToUtf8 isn't the cause.

So it's the malformed no-= entry, and your until (p^=#0) or (p^='=') fixes it. That also explains why it was intermittent for me — the old scan runs off the end into whatever memory is next.

Thanks for the quick fix!