[Bug 58805] New: Chrome Embedded Framework CEF Massive Memory usage
http://bugs.winehq.org/show_bug.cgi?id=58805 Bug ID: 58805 Summary: Chrome Embedded Framework CEF Massive Memory usage Product: Wine Version: 10.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: johnpgoodman(a)gmail.com Distribution: --- Created attachment 79459 --> http://bugs.winehq.org/attachment.cgi?id=79459 memory usage I noticed that recent versions of Logos Bible software make much more use of CEF and so each panel starts up a new process. I'm sure this is true of lots of other apps too. But the problem is on Mac or Windows CEF is very memory light but for some reason each process uses about 250mb of ram on wine. I've investigated this a little and grok suggests that the problem is likely this: Chromium Embedded Framework (CEF) apps like Logos Bible Software spawn multiple renderer processes (~1 per UI panel). On Windows/Mac, each uses 20-50MB RAM by sharing V8 JIT code, Skia graphics caches, and fonts across processes. In Wine on Linux, unshared per-process duplication inflates this to 250MB/process, exhausting RAM with 10+ panels (2.5GB+ total). Root causes: Wine's ntdll doesn't share executable pages; D3D11 re-translates shaders per-process; emulated sandbox adds overhead. It recommends a solution: 3 targeted patches to emulate native sharing: Shared V8 JIT Cache (ntdll/unixlib.c): Map V8's 128MB executable region to /dev/shm once per prefix. Unified Skia/ANGLE Cache (d3d11/utils.c): Global /tmp/wine-angle-cache for shader translations. CEF Sandbox Bypass (Launch flag + winevdm.c): Skip emulated sandboxing. And points out that All Wine CEF Apps would be affected e.g. Discord, VSCode, Steam etc so many 1000s of users. I haven't a great deal of expertise but I've a good track record of working with devs to do testing and builds etc to help patches through. I'd be very grateful for any assistance from a dev with this issue! thanks -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58805 mail@robnewton.me changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mail@robnewton.me --- Comment #1 from mail@robnewton.me --- **Additional evidence: Logos Desktop under Wine on a 16 GB Fedora system** Hello, I am adding some measured evidence that may be relevant to this issue. I am running Logos Bible Software Desktop under Wine on Fedora Aurora (an immutable Fedora-based Linux system) on a Lenovo Yoga 7 16IAP7 laptop with an Intel Core i7-1260P processor, Intel Iris Xe graphics and 16 GB of RAM. My Logos installation was set up using OuDedetai. The Wine version was 10.13, and the Direct3D renderer was set to GDI. I had previously tried DXVK, but encountered flickering and instability, so I reverted to GDI. While Logos Desktop was running, the Linux kernel OOM killer terminated Filen: `Out of memory: Killed process 3689 (Filen)` I also examined the system's `sar` memory statistics around 11:00 am on 13 October 2026 (AEDT). These showed approximately 285 MiB of available memory, 98.2% memory utilisation, and a commit percentage of approximately 209.5%. At the time, Logos was using multiple CEF/Chromium processes. In one observation, there were approximately 17 renderer processes, with reported resident memory of around 6.1 GB for those processes and around 1.2 GB for the main Logos process. Brave was also running. I understand that resident memory figures can include shared pages, so these figures should not be treated as a straightforward sum of unique physical memory usage. Subsequently, attempts to launch Logos Desktop were associated with complete system freezes. I experienced two hard freezes requiring power-button shutdowns, and a further freeze during a reboot/login sequence. I have stopped launching Logos Desktop to avoid further system instability. I cannot establish that the CEF/Wine memory behaviour is the direct cause of the freezes, but the kernel OOM event and memory statistics provide evidence that memory pressure became severe while Logos was running. I examined the saved system activity data (sar -r -f /var/log/sa/sa13) for 13 October 2026. At 11:00:00 am, the system recorded 98.19% memory utilisation, approximately 285 MiB of available memory, and 209.54% committed memory. At 10:40 am, available memory was approximately 1.47 GiB, so the recorded figures show a substantial deterioration over that interval. I had previously observed that the kernel OOM killer terminated Filen while Logos Desktop was running, but I can no longer retrieve the corresponding kernel journal entry to include it here. I therefore cannot provide the original OOM log excerpt as supporting evidence. The same laptop ran Logos on Windows 11 without these problems. I have not repeated the tests to collect more evidence because of the risk of another system freeze. Could this evidence be relevant to Wine bug 58805, particularly regarding CEF subprocess memory use or memory handling under Wine? Is there any specific existing diagnostic information that would help clarify whether this is related to the issue? Thank you. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla