Fatal JavaScript out of memory issue Fedora 39 with XDE Plasma 5 aarch64

[mzavattaro]

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.85.1
Commit: 0ee08df
Date: 2023-12-13T09:48:59.576Z
Electron: 25.9.7
ElectronBuildId: 25551756
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux arm64 6.6.8-200.fc39.aarch64

Steps to Reproduce:

1. Try and open VS Code. In some instances it will successfully open without the fatal error. However, there are some instances when it will error with the fatally. It doesn't always error.

<--- Last few GCs --->

[19188:0x34002e4000]       18 ms: Mark-Compact (reduce) 0.7 (3.0) -> 0.7 (1.8) MB, 1.62 / 0.00 ms  (average mu = 0.023, current mu = 0.016) last resort; GC in old space requested
[19188:0x34002e4000]       19 ms: Mark-Compact (reduce) 0.7 (1.8) -> 0.7 (1.8) MB, 0.71 / 0.00 ms  (average mu = 0.017, current mu = 0.007) last resort; GC in old space requested


<--- JS stacktrace --->


#
# Fatal JavaScript out of memory: CALL_AND_RETRY_LAST
#

/usr/bin/code: line 62: 19188 Trace/breakpoint trap   (core dumped) ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --ms-enable-electron-run-as-node "$@"

Basically when I try to open VS Code in Fedora 39, sometimes (not always) it will throw a 133 error.

[justschen]

I wasn't able to reproduce. does this also occur in insiders (our nightly build)?

[acheronfail]

I'm also encountering this on Fedora 39 (minimal, using i3, also on aarch64). I installed VSCode according to these instructions, and then used code --install-extension ... to install a list of extensions, and noticed that every couple times it ran it started having these OOM errors.

Now, it seems extensions randomly OOM as well with similar errors...

I'll try the latest insiders and see if it happens there, too.

EDIT: it appears the same issue is occurring in the insiders builds, here's an except from my script which just runs code-insiders --install-extension ... several times over:

... (truncated)
Installing extension 'bierner.markdown-mermaid'...
(node:15471) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `code-insiders --trace-deprecation ...` to show where the warning was created)
Extension 'bierner.markdown-mermaid' v1.21.0 was successfully installed.

<--- Last few GCs --->

[15510:0x24002e4000]       40 ms: Mark-Compact (reduce) 0.7 (3.2) -> 0.7 (1.9) MB, 0.99 / 0.00 ms  (average mu = 0.385, current mu = 0.021) last resort; GC in old space requested
[15510:0x24002e4000]       41 ms: Mark-Compact (reduce) 0.7 (1.9) -> 0.7 (1.9) MB, 0.54 / 0.00 ms  (average mu = 0.267, current mu = 0.007) last resort; GC in old space requested


<--- JS stacktrace --->


#
# Fatal JavaScript out of memory: CALL_AND_RETRY_LAST
#

/usr/bin/code-insiders: line 62: 15510 Trace/breakpoint trap   (core dumped) ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" "$@"
... (truncated)

Some information:

$ code-insiders --version
1.86.0-insider
271fb7fbd599b49a1482ea7284a50b3229317f96
arm64

$ uname -a
Linux fedora 6.6.11-200.fc39.aarch64 #1 SMP PREEMPT_DYNAMIC Wed Jan 10 19:51:49 UTC 2024 aarch64 GNU/Linux

When used without extensions, I do see the same error. It's just easier to consistently reproduce when I run several code --install-extension ... commands in a row.

[bpasero]

So this issue does not reproduce without installing extensions? And does it make a difference how you install the extensions (from UI or CLI)?

[acheronfail]

So this issue does not reproduce without installing extensions? And does it make a difference how you install the extensions (from UI or CLI)?

Sorry, I could have been more clear. The issue seems to happen intermittently when executing code. When I run code from the terminal, perhaps 1 in 5 times it OOM's and crashes, then I just try again and it works.

My script which installs extensions does so in a naive manner, and expands to something like:

code --install-extension ext1
code --install-extension ext2
code --install-extension ext3
# and so on...

And since I'm spawning code many times I see the OOM error happen a lot more frequently.

FWIW I did have Arch installed prior to Fedora, and I never saw this issue - my hunch would be that this is something specific to how VSCode is packaged and distributed to Fedora systems.

[bpasero]

Again: does the OOM ever happen when you do not install extensions? I am trying to figure out if the OOM could be related to extension installation or running Code in general.

[acheronfail]

Oh, nah it's not to do with installing extensions, check this out:

❯ while :; do code --version; done
1.85.2
8b3775030ed1a69b13e4f4c628c612102e30a681
arm64
1.85.2
8b3775030ed1a69b13e4f4c628c612102e30a681
arm64
1.85.2
8b3775030ed1a69b13e4f4c628c612102e30a681
arm64
1.85.2
8b3775030ed1a69b13e4f4c628c612102e30a681
arm64

<--- Last few GCs --->

[3997:0x10002e4000]       11 ms: Mark-Compact (reduce) 0.7 (3.0) -> 0.7 (1.8) MB, 1.03 / 0.00 ms  (average mu = 0.024, current mu = 0.012) last resort; GC in old space requested
[3997:0x10002e4000]       11 ms: Mark-Compact (reduce) 0.7 (1.8) -> 0.7 (1.8) MB, 0.52 / 0.00 ms  (average mu = 0.018, current mu = 0.010) last resort; GC in old space requested


<--- JS stacktrace --->


#
# Fatal JavaScript out of memory: CALL_AND_RETRY_LAST
#

/usr/bin/code: line 62:  3997 Trace/breakpoint trap   (core dumped) ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --ms-enable-electron-run-as-node "$@"

<--- Last few GCs --->

[4016:0x4c002e4000]       11 ms: Mark-Compact (reduce) 0.7 (3.0) -> 0.7 (1.8) MB, 0.97 / 0.00 ms  (average mu = 0.019, current mu = 0.013) last resort; GC in old space requested
[4016:0x4c002e4000]       11 ms: Mark-Compact (reduce) 0.7 (1.8) -> 0.7 (1.8) MB, 0.48 / 0.00 ms  (average mu = 0.016, current mu = 0.010) last resort; GC in old space requested


<--- JS stacktrace --->


#
# Fatal JavaScript out of memory: CALL_AND_RETRY_LAST
#

/usr/bin/code: line 62:  4016 Trace/breakpoint trap   (core dumped) ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --ms-enable-electron-run-as-node "$@"
1.85.2
8b3775030ed1a69b13e4f4c628c612102e30a681
arm64
1.85.2
8b3775030ed1a69b13e4f4c628c612102e30a681
arm64
1.85.2
8b3775030ed1a69b13e4f4c628c612102e30a681
arm64

This behaviour happens on a clean install (prior to any extensions being installed in the first place).

[mzavattaro]

Again: does the OOM ever happen when you do not install extensions? I am trying to figure out if the OOM could be related to extension installation or running Code in general.

From my experience testing it with and without extensions installed and enabled and disabled, it makes no difference and the OOM error does still occur.

[bpasero]

Oh wow, thats a pretty easy way to trigger it.

Can you please follow the steps in https://github.com/Microsoft/vscode/wiki/Native-Crash-Issues to get at more details around the crash and attach the result here? Thanks!

[acheronfail]

I did try that, but I think it's crashing a lot earlier than that, so it seems no crash reports are created:

acheronfail@fedora:~/code$ while code --version --crash-reporter-directory /home/acheronfail/code; do :; done

<--- Last few GCs --->

[4025:0x30002e4000]       15 ms: Mark-Compact (reduce) 0.7 (3.0) -> 0.7 (1.8) MB, 1.31 / 0.00 ms  (average mu = 0.022, current mu = 0.014) last resort; GC in old space requested
[4025:0x30002e4000]       16 ms: Mark-Compact (reduce) 0.7 (1.8) -> 0.7 (1.8) MB, 0.73 / 0.00 ms  (average mu = 0.016, current mu = 0.007) last resort; GC in old space requested


<--- JS stacktrace --->


#
# Fatal JavaScript out of memory: CALL_AND_RETRY_LAST
#

/usr/bin/code: line 62:  4025 Trace/breakpoint trap   (core dumped) ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --ms-enable-electron-run-as-node "$@"
acheronfail@fedora:~/code$ ls -la
total 0
drwxr-xr-x. 1 acheronfail acheronfail   0 Jan 26 09:57 .
drwx------. 1 acheronfail acheronfail 326 Jan 26 09:57 ..
acheronfail@fedora:~/code$ uname -a
Linux fedora 6.6.13-200.fc39.aarch64 #1 SMP PREEMPT_DYNAMIC Sat Jan 20 17:56:21 UTC 2024 aarch64 GNU/Linux
acheronfail@fedora:~/code$ 

I was able to replicate this in a VM (QEMU) on a different machine with the following steps:

1. Download Fedora-Workstation-Live-aarch64-39-1.5-respin.iso
2. Boot and install fedora with defaults
3. Once booted into Fedora, follow instructions here to install code
4. Run a sudo dnf upgrade to update the system
5. Reboot
6. After logging in again, run while code --version; do :; done and wait for it to OOM (usually happens in < 5 seconds)

[bpasero]

Is Wayland involved?

[acheronfail]

I tried both on Wayland and X11, and it happened in both cases. I'll try and see if I can build a VM image I can share, to see others can easily reproduce it...

[bpasero]

Yes that would be great.

[acheronfail]

Apologies for the delay - I tried to get this working with only QEMU (not UTM) so it could be run cross-platform but I couldn't get an arm-based VM working with a display in QEMU... UTM makes this very easy.

So, unfortunately to run it you'll need to use UTM for now, until I find the right options to run the image with QEMU (if you figure it out, let me know!). Inside the .utm file is the .qcow2 that QEMU uses, so you can try to experiment with that if you don't have access to a macOS machine.

Here it is:

• Download it here: https://drive.google.com/file/d/1Cj8dF7jvRHOUP5PmjxwZJfGB_DsDV7iv/view?usp=sharing
• Username: acheronfail
• Password: fedora

If you're using UTM I recommend you add a serial interface to it so you can see the boot progress before the display is initialised - if you're running this without a hypervisor it can run quite slowly due to the emulation.

It has code installed. To reproduce the issue, just open the Terminal app and run the following:

# continually call `code --version` until it fails
$ while code --version; do :; done

I've tested this with the following host configurations:

• aarch64 host using Apple Virtualisation
• aarch64 host QEMU (with hypervisor)
• aarch64 host QEMU (no hypervisor)

I did try a few times to get this running on an x86_64 host, but each time I booted the VM both QEMU and UTM failed to initialise the display, so the boot never completed... If I figure out how to fix this, I'll let you know.

In each of them just running the above snippet will reproduce the OOM error. Here's a screenshot:

[VSCodeTriageBot]

Hey @deepak1556, this issue might need further attention.

@mzavattaro, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[VSCodeTriageBot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!