VSCode 1.40 crash after startup with segmentation fault

[deimi]

After upgrading the VSCode Snap package to 1.40, the app crashes immediately after startup with an segmentation fault.
If I revert the snap to 1.39.2, it is working fine.

• VSCode Version:
  1.40
  Snap version 86405ea 2019-11-07
• OS Version:
  Linux Mint 19.2 Cinnamon
  Kernel 4.15.0-66-generic

Steps to Reproduce:

1. Start VSCode
2. Wait about 4 second (with/without user interaction)

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

Screenshot of journalctl

[bpasero]

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!

[kyegupov]

@bpasero I have the same issue.
Ubuntu 19.04 x64 kernel 5.0.0-32-generic
I have tried to follow the instructions in Native-Crash-Issues, but the stack trace is not very readable:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/snap/core/current/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/snap/code/19/usr/share/code/code --no-sandbox'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fb6f2c4f75c in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
[Current thread is 1 (Thread 0x7fb6e0e6f700 (LWP 7337))]
(gdb) bt
#0  0x00007fb6f2c4f75c in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
#1  0x00007fb6f2c58861 in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
#2  0x00007fb6f2c53574 in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
#3  0x00007fb6f2c57db9 in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
#4  0x00007fb6ec2b75ad in ?? () from /snap/core/current/lib/x86_64-linux-gnu/libc.so.6
#5  0x00007fb6f2c53574 in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
#6  0x00007fb6ec2b7664 in __libc_dlopen_mode () from /snap/core/current/lib/x86_64-linux-gnu/libc.so.6
#7  0x00007fb6ec289a85 in ?? () from /snap/core/current/lib/x86_64-linux-gnu/libc.so.6
#8  0x00007fb6f2424a99 in __pthread_once_slow () from /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0
#9  0x00007fb6ec289ba4 in backtrace () from /snap/core/current/lib/x86_64-linux-gnu/libc.so.6
#10 0x000055a00363e2c9 in ?? ()
#11 0x00007fb6e0e6e390 in ?? ()
#12 0x000055a0035a2da3 in ?? ()
#13 0x0000000000000000 in ?? ()

[deimi]

dump.txt

GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /snap/code/19/usr/share/code/code...(no debugging symbols found)...done.
[New LWP 29858]
[New LWP 29864]
[New LWP 29861]
[New LWP 29862]
[New LWP 29871]
[New LWP 29856]
[New LWP 29870]
[New LWP 29866]
[New LWP 29875]
[New LWP 29874]
[New LWP 29892]
[New LWP 29880]
[New LWP 29857]
[New LWP 29877]
[New LWP 29884]
[New LWP 29853]
[New LWP 29882]
[New LWP 29879]
[New LWP 29878]
[New LWP 29873]
[New LWP 29872]
[New LWP 29869]
[New LWP 29894]
[New LWP 29854]
[New LWP 29867]
[New LWP 29863]
[New LWP 29859]
[New LWP 29865]
[New LWP 29868]
[New LWP 29881]
[New LWP 29860]

warning: File "/snap/core/8039/lib/x86_64-linux-gnu/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /snap/core/8039/lib/x86_64-linux-gnu/libthread_db-1.0.so
line to your configuration file "/home/mat/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/mat/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

warning: File "/snap/core/8039/lib/x86_64-linux-gnu/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
Core was generated by `/snap/code/19/usr/share/code/code --no-sandbox .'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f66c9da975c in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
[Current thread is 1 (LWP 29858)]
(gdb)

[bpasero]

Ok, let's wait for Deepak to comment on the crash and how to proceed.

[incomingstick]

I am experiencing this same segfault as well after the upgrade to 1.40, running Arch Linux Kernel 5.3.8

[bpasero]

Are people seeing this when running the archive'd version of VSCode too? Download: https://az764295.vo.msecnd.net/stable/86405ea23e3937316009fc27c9361deee66ffbf5/code-stable-1573064450.tar.gz

From the command line run: code --no-sandbox

[3v1n0]

Running that archive looks fine here, while the snap crashes indeed.

Dmesg also contains:

[ 1993.813733] Chrome_IOThread[26090]: segfault at 38 ip 00007fd1fb66275c sp 00007fd1e9c51d20 error 4 in ld-2.23.so[7fd1fb656000+26000]
[ 1993.813738] Code: 41 c1 e1 02 81 e2 ff 7f 00 00 41 09 c1 4d 89 bc 24 f8 03 00 00 48 8d 14 52 45 89 8c 24 00 04 00 00 4c 8d 04 d6 4d 85 c0 74 0f <41> 8b 40 08 85 c0 b8 00 00 00 00 4c 0f 44 c0 41 8b 3f 48 8b 8d 40
[ 2346.762302] Chrome_IOThread[27366]: segfault at 38 ip 00007fabccccd75c sp 00007fabbb2bcd20 error 4 in ld-2.23.so[7fabcccc1000+26000]
[ 2346.762309] Code: 41 c1 e1 02 81 e2 ff 7f 00 00 41 09 c1 4d 89 bc 24 f8 03 00 00 48 8d 14 52 45 89 8c 24 00 04 00 00 4c 8d 04 d6 4d 85 c0 74 0f <41> 8b 40 08 85 c0 b8 00 00 00 00 4c 0f 44 c0 41 8b 3f 48 8b 8d 40

[bpasero]

Adding @joaomoreno and @Tyriar given this seems to be a crash in Snap only?

[Tyriar]

cc @flexiondotorg

[pipobscure]

I get a similar thing with v1.40 on Windows 10. I think this may be an electron 6 issue (has similar happen in my own electron app which triggered update to v7 😄 )

PS C:\Users\UserName> & 'C:\Users\UserName\AppData\Local\Programs\Microsoft VS Code\Code.exe'                                                                                                           PS C:\Users\UserName>
 [main 2019-11-11T20:15:16.355Z] update#setState idle
Windows PowerShell[5136]: ../../third_party/electron_node/src/inspector_agent.cc:810: Assertion `(client_) != nullptr' failed.
 1: 00007FF6C954C9E2 node::EmitAsyncDestroy+11839202
 2: 00007FF6C89D9A96 node::Abort+22
 3: 00007FF6C89D9623 node::Assert+131
 4: 00007FF6C89E44BD node::inspector::Agent::Connect+253
 5: 00007FF6C960C829 uv_udp_set_multicast_loop+457321
 6: 00007FF6C960DAA7 uv_udp_set_multicast_loop+462055
 7: 00007FF6C89FA294 uv_loop_delete+6724
 8: 00007FF6C89FD2E4 node::BootstrapEnvironment+52
 9: 00007FF6C89FD24C node::CreateEnvironment+268
10: 00007FF6C89F9875 uv_loop_delete+4133
11: 00007FF6C89EF185 uv_key_set+28101
12: 00007FF6C9591409 uv_translate_sys_error+206665
13: 00007FF6C896155D uv_fs_get_statbuf+5917277
14: 00007FF6C7C51879 uv_cond_broadcast+62537
15: 00007FF6C82CF879 node::AsyncResource::get_async_id+2248441
16: 00007FF6C7C7ACD0 uv_cond_broadcast+231584
17: 00007FF6C7C57FB5 uv_cond_broadcast+88965
18: 00007FF6C7C582E8 uv_cond_broadcast+89784
19: 00007FF6C833B962 node::AsyncResource::get_async_id+2691042
20: 00007FF6C958FE4B uv_translate_sys_error+201099
21: 00007FF6C895BF67 uv_fs_get_statbuf+5895271
22: 00007FF6C90466CF node::EmitAsyncDestroy+6570959
23: 00007FF6C8699144 uv_fs_get_statbuf+2999876
24: 00007FF6C8695708 uv_fs_get_statbuf+2984968
25: 00007FF6C8694964 uv_fs_get_statbuf+2981476
26: 00007FF6C869754B uv_fs_get_statbuf+2992715
27: 00007FF6C86A5C66 uv_fs_get_statbuf+3051878
28: 00007FF6C83414FF node::AsyncResource::get_async_id+2714495
29: 00007FF6C895572B uv_fs_get_statbuf+5868587
30: 00007FF6C899D1F1 uv_fs_get_statbuf+6162161
31: 00007FF6C899D039 uv_fs_get_statbuf+6161721
32: 00007FF6C8954C5C uv_fs_get_statbuf+5865820
33: 00007FF6C8954430 uv_fs_get_statbuf+5863728
34: 00007FF6C5AB6A12 node::InternalCallbackScope::Failed+312674
35: 00007FF6C899C68A uv_fs_get_statbuf+6159242
36: 00007FF6C7478FB0 GetHandleVerifier+635376
37: 00007FF6C8B24AF1 node::EmitAsyncDestroy+1189873
38: 00007FF6C8B24B74 node::EmitAsyncDestroy+1190004
39: 00007FF6C7376BB0 uv_cond_signal+11648
40: 00007FF6C7385D26 uv_cond_signal+73462
41: 00007FF6C73859CC uv_cond_signal+72604
42: 00007FF6C73393BC uv_loadavg+855692
43: 00007FF6C73865E6 uv_cond_signal+75702
44: 00007FF6C735C2CE uv_os_getpid+66926
45: 00007FF6C898B38D uv_fs_get_statbuf+6088845
46: 00007FF6C5EC24DC v8::String::Value::operator*+331020
47: 00007FF6C7B4668A IsSandboxedProcess+204602
48: 00007FF6C5EC1CE6 v8::String::Value::operator*+328982
49: 00007FF6C56E13BF Ordinal0+5055
50: 00007FF6CA35D342 node::AsyncResource::CallbackScope::CallbackScope+4046130
51: 00007FFF3F077BD4 BaseThreadInitThunk+20
52: 00007FFF401CCED1 RtlUserThreadStart+33
[main 2019-11-11T20:15:16.685Z] [VS Code]: render process crashed!
Windows PowerShell[8684]: ../../third_party/electron_node/src/inspector_agent.cc:810: Assertion `(client_) != nullptr' failed.
 1: 00007FF6C954C9E2 node::EmitAsyncDestroy+11839202
 2: 00007FF6C89D9A96 node::Abort+22
 3: 00007FF6C89D9623 node::Assert+131
 4: 00007FF6C89E44BD node::inspector::Agent::Connect+253
 5: 00007FF6C960C829 uv_udp_set_multicast_loop+457321
 6: 00007FF6C960DAA7 uv_udp_set_multicast_loop+462055
 7: 00007FF6C89FA294 uv_loop_delete+6724
 8: 00007FF6C89FD2E4 node::BootstrapEnvironment+52
 9: 00007FF6C89FD24C node::CreateEnvironment+268
10: 00007FF6C89F9875 uv_loop_delete+4133
11: 00007FF6C89EF185 uv_key_set+28101
12: 00007FF6C9591409 uv_translate_sys_error+206665
13: 00007FF6C896155D uv_fs_get_statbuf+5917277
14: 00007FF6C7C51879 uv_cond_broadcast+62537
15: 00007FF6C82CF879 node::AsyncResource::get_async_id+2248441
16: 00007FF6C7C7ACD0 uv_cond_broadcast+231584
17: 00007FF6C7C57FB5 uv_cond_broadcast+88965
18: 00007FF6C7C582E8 uv_cond_broadcast+89784
19: 00007FF6C833B962 node::AsyncResource::get_async_id+2691042
20: 00007FF6C958FE4B uv_translate_sys_error+201099
21: 00007FF6C895BF67 uv_fs_get_statbuf+5895271
22: 00007FF6C90466CF node::EmitAsyncDestroy+6570959
23: 00007FF6C8699144 uv_fs_get_statbuf+2999876
24: 00007FF6C8695708 uv_fs_get_statbuf+2984968
25: 00007FF6C8694964 uv_fs_get_statbuf+2981476
26: 00007FF6C869754B uv_fs_get_statbuf+2992715
27: 00007FF6C86A5C66 uv_fs_get_statbuf+3051878
28: 00007FF6C83414FF node::AsyncResource::get_async_id+2714495
29: 00007FF6C895572B uv_fs_get_statbuf+5868587
30: 00007FF6C899D1F1 uv_fs_get_statbuf+6162161
31: 00007FF6C899D039 uv_fs_get_statbuf+6161721
32: 00007FF6C8954C5C uv_fs_get_statbuf+5865820
33: 00007FF6C8954430 uv_fs_get_statbuf+5863728
34: 00007FF6C5AB6A12 node::InternalCallbackScope::Failed+312674
35: 00007FF6C899C68A uv_fs_get_statbuf+6159242
36: 00007FF6C7478FB0 GetHandleVerifier+635376
37: 00007FF6C8B24AF1 node::EmitAsyncDestroy+1189873
38: 00007FF6C8B24B74 node::EmitAsyncDestroy+1190004
39: 00007FF6C7376BB0 uv_cond_signal+11648
40: 00007FF6C7385D26 uv_cond_signal+73462
41: 00007FF6C73859CC uv_cond_signal+72604
42: 00007FF6C73393BC uv_loadavg+855692
43: 00007FF6C73865E6 uv_cond_signal+75702
44: 00007FF6C735C2CE uv_os_getpid+66926
45: 00007FF6C898B38D uv_fs_get_statbuf+6088845
46: 00007FF6C5EC24DC v8::String::Value::operator*+331020
47: 00007FF6C7B4668A IsSandboxedProcess+204602
48: 00007FF6C5EC1CE6 v8::String::Value::operator*+328982
49: 00007FF6C56E13BF Ordinal0+5055
50: 00007FF6CA35D342 node::AsyncResource::CallbackScope::CallbackScope+4046130
51: 00007FFF3F077BD4 BaseThreadInitThunk+20
52: 00007FFF401CCED1 RtlUserThreadStart+33

[pipobscure]

Possibly related (cursory search only, bag of salt appropriate):

• repl.start Causes Crash in Renderer electron/electron#18872
• inspector: split main thread interface from transport nodejs/node#21182

[deimi]

The new version 1.40.1 is still crashing

[deepak1556]

I tested on Ubuntu 18.04 with the snap package, from terminal did

> /snap/code/20/usr/share/code/code somefolder

waited for sometime with no interactions but didn't see a crash as reported. Is there something else I need to perform for the crash to happen ?

[deimi]

No, not really. It's even enough to open code without a folder parameter.

It also seems that the failure is also dependent on your hardware/OS.
On my private Dell XPS13 with Linux Mint 19.2 it is working fine. My colleague has a Lenovo P51 with Debian and there it is working fine too. On the other hand, on my business P51 with Mint 19.2 it is always crashing.

P.s.: Just in case it makes any difference. I'm calling code without directory.
> code somefolder

> which code
/snap/bin/code
> ls -la /snap/bin/code
lrwxrwxrwx 1 root root 13 Nov 17 18:13 /snap/bin/code -> /usr/bin/snap

[ghost]

I also experience crashes of VS Code version 1.40.1 on Ubuntu 19.10. Here is output of syslog:

Nov 22 21:20:49 kernel: [ 7644.047173] Chrome_IOThread[29938]: segfault at 38 ip 00007f56629e675c sp 00007f565098ad20 error 4 in ld-2.23.so[7f56629da000+26000]
Nov 22 21:20:49 kernel: [ 7644.047187] Code: 41 c1 e1 02 81 e2 ff 7f 00 00 41 09 c1 4d 89 bc 24 f8 03 00 00 48 8d 14 52 45 89 8c 24 00 04 00 00 4c 8d 04 d6 4d 85 c0 74 0f <41> 8b 40 08 85 c0 b8 00 00 00 00 4c 0f 44 c0 41 8b 3f 48 8b 8d 40

The same version of VS code doesn't crash if installed via .deb package.

[deepak1556]

I will try with Ubuntu 19 today if it doesn't work will try to create a snap package with debug version of vscode , so that we can get better stack trace from your end. Also electron just fixed generating debug symbols for linux electron/electron#18676, if I can that in 6.1.x version of our release that will also help.

[deepak1556]

I tried 1.40.1 snap package with Ubuntu 19.10 on parallels vm, but I couldn't see any crash even after using the editor for a while. I will get the debug symbols as next step to investigate further.

[ghost]

Can confirm that it neither crashes on fresh Ubuntu 19.10 installation to Virtualbox. I found some recommendations to run VS Code with disabled GPU, but it doesn't resolve the issue.

[deimi]

The new version 1.40.2 is still crashing

[deimi]

@deepak1556 Any updates to this issue?

[deimi]

The new version 1.41 is still crashing

[deepak1556]

@deimi sorry for the delay, we are updating to a newer version 6.1.6 #86837 which will be available in the next insiders and has better debug symbols support from electron, I am hoping that will get this issue moving forward.

[incomingstick]

v1.41 no longer crashes for me on Arch Linux Kernel v5.4.2

[3v1n0]

It still crashes for me instead :(

[3v1n0]

@deepak1556 any action I can do to help move forward this issue?

I've tried to run 1.4.1 using gdb, both using snap to run it or just manually runnig the binary, but in both cases I'm getting the same crash for which gdb isn't really helpful:

#0  0x00007ffff7de375c in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
#1  0x00007ffff7dec861 in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
#2  0x00007ffff7de7574 in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
#3  0x00007ffff7debdb9 in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
#4  0x00007ffff144b5ad in ?? () from /snap/core/current/lib/x86_64-linux-gnu/libc.so.6
#5  0x00007ffff7de7574 in ?? () from /snap/core/current/lib64/ld-linux-x86-64.so.2
#6  0x00007ffff144b664 in __libc_dlopen_mode () from /snap/core/current/lib/x86_64-linux-gnu/libc.so.6
#7  0x00007ffff141da85 in ?? () from /snap/core/current/lib/x86_64-linux-gnu/libc.so.6
#8  0x00007ffff75b8a99 in __pthread_once_slow () from /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0
#9  0x00007ffff141dba4 in backtrace () from /snap/core/current/lib/x86_64-linux-gnu/libc.so.6
#10 0x00005555589d3db9 in ?? ()
#11 0x00007fffe5bd2390 in ?? ()
#12 0x0000555558938893 in ?? ()
#13 0x0000000000000000 in ?? ()

---

I assume there's some problem with the libraries the snap is loading, because if I run the snap from the deb, extracting the binaries, I've no such crash.

Nothing else a part from polling in the other threads.

I assume I would need a version with better symbols though.

[deimi]

The new version 1.42 is still crashing

[askvortsov1]

Still an issue for me as well.

[3v1n0]

Confirm crashes continue.

Also, nor --disable-extensions or --disable-gpu works

Attaching the --verbose logging with both the snap (code-verbose-snap.log) and the tar.gz (code-verbose-tar-gz.log) versions.

The snap ends with something like

[16970:0212/155343.582711:ERROR:nss_util.cc(748)] After loading Root Certs, loaded==false: NSS error code: -8018
Server response: <?xml version="1.0" encoding="UTF-8"
[17075:0212/155351.020577:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)
[17075:0212/155351.020612:FATAL:memory.cc(22)] Out of memory. size=262144
[17015:0212/155351.038297:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)
[17015:0212/155351.038331:FATAL:memory.cc(22)] Out of memory. size=262144

Not sure the nss error is the one bringing the fatal issue though, while the "Out of memory" thing doesn't seem to be possible to be muted by using --max-memory either with some bigger number.

[deimi]

It seems that with the new version 1.43, all is working fine now. At least for me...
The others (@askvortsov1 @3v1n0 @tasmanianfox) should check as well, so we can close this issue.

@deepak1556 either it was the update to Electron 7.0 or any other change

[3v1n0]

I can confirm this works, you can close the issue from my POV.

[ghost]

Works for me too.