Summary
On our setup, every overlay browser creation crashes gta_sa.exe, including
a page containing nothing but static HTML (no JavaScript, no external requests).
The crash is always heap corruption (0xc0000374), but the reported stack
differs between runs, which is consistent with memory being corrupted earlier
and detected at the next free.
The game and SA-MP are stable for hours as long as no browser is created.
Environment
|
|
| omp-cef |
1.3.0 (client client.dll/renderer.exe 1.3.0.0, server component v1.3.0) |
| CEF/Chromium |
148.0.7778.218 |
| SA-MP |
0.3.DL-R1 (detected correctly by the plugin) |
| Server |
open.mp, Linux x86 component, C++ gamemode using ICefComponent |
| OS |
Windows 11, build 26200, 64-bit |
| Display |
windowed |
Reproduction
- Register a resource with a panel whose
index.html is static HTML only.
- Call
ICefComponent::createBrowser(playerid, 1000, "http://cef/ui/panels/test/index.html", false, true).
- The page loads successfully, then the game crashes 2-3 seconds later.
The panel used for the last test:
<!doctype html>
<html lang="ro">
<head>
<meta charset="UTF-8" />
<link rel="icon" href="data:," />
<title>test</title>
<style>body{margin:0;display:grid;place-items:center;height:100vh;background:#101014;color:#ffbb3d;font:600 28px sans-serif}</style>
</head>
<body><div>TEST</div></body>
</html>client.log (debug enabled), last lines before the crash
[D3D9] Hooks installed: Reset=0x6cdc09d0, BeginScene=0x6cd46620, EndScene=0x6cd46720, Present=0x6cdc05d0
Detected SA-MP version : 0.3.DL-R1
[D3D9] Captured device via Present: device=0x129c0fc0, hwnd=0x0
...
[CEF] CreateBrowser called with ID=1000, url=http://cef/ui/panels/test/index.html
[ViewTexture] Creating texture 800x600
[CEF] Successfully loaded: panels/test/index.html from resource 'ui'
<- crash here, no further lines
Shutdown omp-cef client app ...
Two things stand out in every single session, regardless of the crash:
[WARN] [D3D9] Bootstrap hooks failed (dummy device). Will rely on PollD3D fallback.
[D3D9] Captured device via Present: device=..., hwnd=0x0
The dummy-device bootstrap never succeeds here, so the device is always acquired
through the polling fallback, and it is captured with hwnd=0x0.
Crash stacks (cdb, from %LOCALAPPDATA%\CrashDumps)
Three different runs, three different stacks, all 0xc0000374:
1 — inside libcef, freeing:
ntdll!RtlpReportHeapFailure
ntdll!RtlFreeHeap
libcef!GetHandleVerifier+0x1a1aa39
libcef!... (whole stack)
2 — Windows Text Services, freeing, on an input-focus event:
ntdll!RtlFreeHeap
KERNELBASE!LocalFree
msctf!CTextStoreImpl::RetrieveRequestedAttrs
textinputframework!CACPWrap::RetrieveRequestedAttrs
msctf!CThreadInputMgr::OnInputFocusEvent
msctf!WinEventProc
3 — secondary crash, reproducible on every run: after the first exception,
GTA's handler calls ExitProcess(0xc0000005), and client.dll then faults again
during DLL_PROCESS_DETACH:
kernel32!ExitProcessImplementation
ntdll!LdrShutdownProcess
ntdll!LdrxCallInitRoutine
client+0x1ae1fc
client+0x1a7bca <- access violation
That last one happens every time and turns any recoverable error into a hard
crash; it may be worth fixing independently.
It also crashes on the plugin's OWN browser
In a later session the game crashed before the player could log in or issue
any command, with the only browser being the plugin's internal download
dialog:
[ResourceManager] Starting download for 1 file(s):
[HudManager] Class selection visibility set to 0.
[CEF] CreateBrowser called with ID=999999, url=http://cef/__internal/loading.html
[DownloadDialog] Started (1 file(s), 205850 bytes).
[ViewTexture] Creating texture 800x600
[ResourceManager] File 'ui.pak' saved successfully (205850 bytes)
<- game crashed ~27s later, nothing else logged
Server side confirms no command was ever run: the player joined at 11:41:56,
RequestJoin at 11:41:58, and disconnected at 11:42:43 without authenticating.
So no gamemode code of ours is involved at all. Any live browser eventually
kills the process, whether it is ours or the plugin's own.
Possible lead: texture size vs. backbuffer pitch
The view texture is always created at 800x600 (createBrowser in the C++
extension API exposes no width/height, unlike the Pawn native). The SA-MP crash
handler dump for the first crash contained, on the same stack region, both the
800x600 dimensions and values that look like a 1920-wide surface pitch:
ESI: 0x00000258 (600) EDI: 0x00000320 (800)
... 0x00001E00 (7680 = 1920 * 4) 0x000010E0 (4320 = 1080 * 4)
together with what appears to be a D3DCAPS9 block (0xFFFE0300, 0xFFFF0300
= vs_3_0 / ps_3_0). That would be consistent with a copy that uses the
backbuffer pitch while writing into the smaller browser texture, which would
overrun the allocation and match the "corruption detected later, elsewhere"
behaviour. We have not been able to confirm this from the outside.
What we ruled out
- Our page — a static HTML page with no JS crashes identically.
- Our resources — the log shows every file loading successfully.
- CEF locale files — full, unmodified set shipped.
- Elevation / compat shims —
__COMPAT_LAYER was inherited from an elevated
parent at one point (this loaded AcLayers/apphelp into renderer.exe and
killed it in combase!DllMain -> TpAllocTimer); we now strip that variable
when launching the game, and the shim is gone. The crash remains.
- Chromium sandbox — subprocess command line already has
--no-sandbox.
- Version mismatch —
ICefComponent header matches the official one; client
and server component are both 1.3.0.
- Page Heap — enabling it changes the outcome (the D3D9 device polling no
longer completes in time and hooks are never installed), so it cannot be used
to narrow this down further.
Note
We cannot A/B against 1.2.0: ICefComponent only exists from 1.3.0, and our
gamemode is C++.
Happy to provide the dumps, the full client.log, or run any instrumented build.
Summary
On our setup, every overlay browser creation crashes
gta_sa.exe, includinga page containing nothing but static HTML (no JavaScript, no external requests).
The crash is always heap corruption (
0xc0000374), but the reported stackdiffers between runs, which is consistent with memory being corrupted earlier
and detected at the next
free.The game and SA-MP are stable for hours as long as no browser is created.
Environment
client.dll/renderer.exe1.3.0.0, server component v1.3.0)ICefComponentReproduction
index.htmlis static HTML only.ICefComponent::createBrowser(playerid, 1000, "http://cef/ui/panels/test/index.html", false, true).The panel used for the last test:
client.log (debug enabled), last lines before the crash
Two things stand out in every single session, regardless of the crash:
The dummy-device bootstrap never succeeds here, so the device is always acquired
through the polling fallback, and it is captured with
hwnd=0x0.Crash stacks (cdb, from
%LOCALAPPDATA%\CrashDumps)Three different runs, three different stacks, all
0xc0000374:1 — inside libcef, freeing:
2 — Windows Text Services, freeing, on an input-focus event:
3 — secondary crash, reproducible on every run: after the first exception,
GTA's handler calls
ExitProcess(0xc0000005), andclient.dllthen faults againduring
DLL_PROCESS_DETACH:That last one happens every time and turns any recoverable error into a hard
crash; it may be worth fixing independently.
It also crashes on the plugin's OWN browser
In a later session the game crashed before the player could log in or issue
any command, with the only browser being the plugin's internal download
dialog:
Server side confirms no command was ever run: the player joined at 11:41:56,
RequestJoinat 11:41:58, and disconnected at 11:42:43 without authenticating.So no gamemode code of ours is involved at all. Any live browser eventually
kills the process, whether it is ours or the plugin's own.
Possible lead: texture size vs. backbuffer pitch
The view texture is always created at 800x600 (
createBrowserin the C++extension API exposes no width/height, unlike the Pawn native). The SA-MP crash
handler dump for the first crash contained, on the same stack region, both the
800x600 dimensions and values that look like a 1920-wide surface pitch:
together with what appears to be a
D3DCAPS9block (0xFFFE0300,0xFFFF0300= vs_3_0 / ps_3_0). That would be consistent with a copy that uses the
backbuffer pitch while writing into the smaller browser texture, which would
overrun the allocation and match the "corruption detected later, elsewhere"
behaviour. We have not been able to confirm this from the outside.
What we ruled out
__COMPAT_LAYERwas inherited from an elevatedparent at one point (this loaded
AcLayers/apphelpintorenderer.exeandkilled it in
combase!DllMain->TpAllocTimer); we now strip that variablewhen launching the game, and the shim is gone. The crash remains.
--no-sandbox.ICefComponentheader matches the official one; clientand server component are both 1.3.0.
longer completes in time and hooks are never installed), so it cannot be used
to narrow this down further.
Note
We cannot A/B against 1.2.0:
ICefComponentonly exists from 1.3.0, and ourgamemode is C++.
Happy to provide the dumps, the full
client.log, or run any instrumented build.