Reproducible Coredump in Stable NixOS with vscode

Help
1

I just switched over from Arch this weekend (yay) and happy to be here, mostly. But one challenge I am having is with VSCode Dev setup. My build scripts for my C# project. which worked in Arch, all crashed with no log info. I figured I did something wrong in my Nix build so I rebuilt again. same thing. Then I figured I had VSCode wired wrong. Took the config to metal and rebuilt. same thing. I took a leap of logic and suspected maybe it was a coredump. Sure enough, it is. Now I really am over my skis at this point as I cannot read a coredump to save my life, but it looks like it is dumping at nix-ld. I figured I was beyond my ability to figure this one out so I am looking for any kind guidance on next steps I should take.

PID: 29915 (vsdbg-ui)

TID: 29915 (vsdbg-ui)

UID: 1000 (aaronw)

GID: 100 (users)

Signal: 6 (ABRT) si_code: SI_TKILL

Timestamp: Tue 2026-07-28 12:34:05 EDT (7s ago)

Command Line: /home/aaronw/.vscode/extensions/ms-dotnettools.csharp-2.140.9-linux-x64/.debugger/vsdbg-ui

Executable: /home/aaronw/.vscode/extensions/ms-dotnettools.csharp-2.140.9-linux-x64/.debugger/vsdbg-ui

Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-code-19677.scope

Unit: user@1000.service

User Unit: app-code-19677.scope

Slice: user-1000.slice

Owner UID: 1000 (aaronw)

Boot ID: 31b79e475491465f8b974e35a5509f21

Machine ID: 4d5b9cb85bb44a0cb1efe25668dccad1

Hostname: Grimlock

Storage: /var/lib/systemd/coredump/core.vsdbg-ui.1000.31b79e475491465f8b974e35a5509f21.29915.1785256445000000.zst (present)

Size on Disk: 2.7M

Message: Process 29915 (vsdbg-ui) of user 1000 dumped core.

Module /nix/store/3wqikrdwv1k6cr74450kb117vrq98xg3-nix-ld-2.0.6/bin/nix-ld without build-id.

Module libgcc_s.so.1 without build-id.

Module libvsbaseservices.so without build-id.

Module libstdc++.so.6 without build-id.

Module libvsdebugeng.so without build-id.

Module vsdbg-ui without build-id.

Stack trace of thread 29915:

#0 0x00007fc36a69fdcc __pthread_kill_implementation (libc.so.6 + 0x9fdcc)

#1 0x00007fc36a64265e raise (libc.so.6 + 0x4265e)

#2 0x00007fc36a629350 abort (libc.so.6 + 0x29350)

#3 0x00007fc369c36e89 n/a (libcoreclr.so + 0x636e89)

#4 0x00007fc369c36da9 n/a (libcoreclr.so + 0x636da9)

#5 0x00007fc369a870c7 n/a (libcoreclr.so + 0x4870c7)

#6 0x00007fc3698e5d8b n/a (libcoreclr.so + 0x2e5d8b)

#7 0x00007fc2ea79ccd3 n/a (n/a + 0x0)

#8 0x00007fc2ea79cc2f n/a (n/a + 0x0)

#9 0x00007fc369bf945c n/a (libcoreclr.so + 0x5f945c)

#10 0x00007fc369a57b81 n/a (libcoreclr.so + 0x457b81)

#11 0x00007fc369a57d92 n/a (libcoreclr.so + 0x457d92)

#12 0x00007fc3699db6cd n/a (libcoreclr.so + 0x3db6cd)

#13 0x00007fc3699dbc35 n/a (libcoreclr.so + 0x3dbc35)

#14 0x00007fc3699fdab4 n/a (libcoreclr.so + 0x3fdab4)

#15 0x00007fc3699febd7 n/a (libcoreclr.so + 0x3febd7)

#16 0x00007fc369bf9607 n/a (libcoreclr.so + 0x5f9607)

#17 0x00007fc2ea8319e5 n/a (n/a + 0x0)

#18 0x00007fc2ea8330af n/a (n/a + 0x0)

#19 0x00007fc2eb7662ba n/a (n/a + 0x0)

#20 0x00007fc2eb766ee7 n/a (n/a + 0x0)

#21 0x00007fc2eb681927 n/a (n/a + 0x0)

#22 0x000000000040157e main (vsdbg-ui + 0x157e)

#23 0x00007fc36a62b285 __libc_start_call_main (libc.so.6 + 0x2b285)

#24 0x00007fc36a62b338 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2b338)

#25 0x0000000000401308 _start (vsdbg-ui + 0x1308)

Stack trace of thread 29917:

#0 0x00007fc36a6a6922 __syscall_cancel_arch (libc.so.6 + 0xa6922)

#1 0x00007fc36a69a00c __internal_syscall_cancel (libc.so.6 + 0x9a00c)

#2 0x00007fc36a69a084 __syscall_cancel (libc.so.6 + 0x9a084)

#3 0x00007fc36a71778e __poll (libc.so.6 + 0x11778e)

#4 0x00007fc369c30fae n/a (libcoreclr.so + 0x630fae)

#5 0x00007fc369c3afb9 n/a (libcoreclr.so + 0x63afb9)

#6 0x00007fc36a69dd53 start_thread (libc.so.6 + 0x9dd53)

#7 0x00007fc36a72563c __clone3 (libc.so.6 + 0x12563c)

Stack trace of thread 29916:

#0 0x00007fc36a6a6922 __syscall_cancel_arch (libc.so.6 + 0xa6922)

#1 0x00007fc36a69a00c __internal_syscall_cancel (libc.so.6 + 0x9a00c)

#2 0x00007fc36a69a084 __syscall_cancel (libc.so.6 + 0x9a084)

#3 0x00007fc36a71778e __poll (libc.so.6 + 0x11778e)

#4 0x00007fc36b76e4e0 _ZN7CorUnix26CPalSynchronizationManager24ReadBytesFromProcessPipeEiPhi (libvsbaseservices.so + 0x414e0)

#5 0x00007fc36b76db23 _ZN7CorUnix26CPalSynchronizationManager22ReadCmdFromProcessPipeEiPNS0_14SynchWorkerCmdEPPvPj (libvsbaseservices.so + 0x40b23)

#6 0x00007fc36b775a42 _ZN7CorUnix10CPalThread11ThreadEntryEPv (libvsbaseservices.so + 0x48a42)

#7 0x00007fc36a69dd53 start_thread (libc.so.6 + 0x9dd53)

#8 0x00007fc36a72563c __clone3 (libc.so.6 + 0x12563c)

Stack trace of thread 29918:

#0 0x00007fc36a6a6922 __syscall_cancel_arch (libc.so.6 + 0xa6922)

#1 0x00007fc36a69a00c __internal_syscall_cancel (libc.so.6 + 0x9a00c)

#2 0x00007fc36a69a084 __syscall_cancel (libc.so.6 + 0x9a084)

#3 0x00007fc36a71778e __poll (libc.so.6 + 0x11778e)

#4 0x00007fc36987c178 n/a (libcoreclr.so + 0x27c178)

#5 0x00007fc3697f52c9 n/a (libcoreclr.so + 0x1f52c9)

#6 0x00007fc3697fa112 n/a (libcoreclr.so + 0x1fa112)

#7 0x00007fc369c3afb9 n/a (libcoreclr.so + 0x63afb9)

#8 0x00007fc36a69dd53 start_thread (libc.so.6 + 0x9dd53)

#9 0x00007fc36a72563c __clone3 (libc.so.6 + 0x12563c)

Stack trace of thread 29921:

#0 0x00007fc36a6a6922 __syscall_cancel_arch (libc.so.6 + 0xa6922)

#1 0x00007fc36a69a00c __internal_syscall_cancel (libc.so.6 + 0x9a00c)

#2 0x00007fc36a69a78c __futex_abstimed_wait_common (libc.so.6 + 0x9a78c)

#3 0x00007fc36a69d400 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x9d400)

#4 0x00007fc369c2f635 n/a (libcoreclr.so + 0x62f635)

#5 0x00007fc369c2f2bf n/a (libcoreclr.so + 0x62f2bf)

#6 0x00007fc369c33d50 n/a (libcoreclr.so + 0x633d50)

#7 0x00007fc369c33f59 n/a (libcoreclr.so + 0x633f59)

#8 0x00007fc369b1020b n/a (libcoreclr.so + 0x51020b)

#9 0x00007fc369a913af n/a (libcoreclr.so + 0x4913af)

#10 0x00007fc369a91537 n/a (libcoreclr.so + 0x491537)

#11 0x00007fc369a2401c n/a (libcoreclr.so + 0x42401c)

#12 0x00007fc369a91aba n/a (libcoreclr.so + 0x491aba)

#13 0x00007fc369c3afb9 n/a (libcoreclr.so + 0x63afb9)

#14 0x00007fc36a69dd53 start_thread (libc.so.6 + 0x9dd53)

#15 0x00007fc36a72563c __clone3 (libc.so.6 + 0x12563c)

Stack trace of thread 29920:

#0 0x00007fc36a6a6922 __syscall_cancel_arch (libc.so.6 + 0xa6922)

#1 0x00007fc36a69a00c __internal_syscall_cancel (libc.so.6 + 0x9a00c)

#2 0x00007fc36a69a78c __futex_abstimed_wait_common (libc.so.6 + 0x9a78c)

#3 0x00007fc36a69d1ee pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x9d1ee)

#4 0x00007fc369c2f692 n/a (libcoreclr.so + 0x62f692)

#5 0x00007fc369c2f2bf n/a (libcoreclr.so + 0x62f2bf)

#6 0x00007fc369c33d50 n/a (libcoreclr.so + 0x633d50)

#7 0x00007fc369c34033 n/a (libcoreclr.so + 0x634033)

#8 0x00007fc369874254 n/a (libcoreclr.so + 0x274254)

#9 0x00007fc3698740b0 n/a (libcoreclr.so + 0x2740b0)

#10 0x00007fc369873db5 n/a (libcoreclr.so + 0x273db5)

#11 0x00007fc369c3afb9 n/a (libcoreclr.so + 0x63afb9)

#12 0x00007fc36a69dd53 start_thread (libc.so.6 + 0x9dd53)

#13 0x00007fc36a72563c __clone3 (libc.so.6 + 0x12563c)

Stack trace of thread 29922:

#0 0x00007fc36a6a6922 __syscall_cancel_arch (libc.so.6 + 0xa6922)

#1 0x00007fc36a69a00c __internal_syscall_cancel (libc.so.6 + 0x9a00c)

#2 0x00007fc36a69a78c __futex_abstimed_wait_common (libc.so.6 + 0x9a78c)

#3 0x00007fc36a69d400 pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x9d400)

#4 0x00007fc369c2f635 n/a (libcoreclr.so + 0x62f635)

#5 0x00007fc369c2f2bf n/a (libcoreclr.so + 0x62f2bf)

#6 0x00007fc369c344e9 n/a (libcoreclr.so + 0x6344e9)

#7 0x00007fc369a2790a n/a (libcoreclr.so + 0x42790a)

#8 0x00007fc369a277c8 n/a (libcoreclr.so + 0x4277c8)

#9 0x00007fc369a2401c n/a (libcoreclr.so + 0x42401c)

#10 0x00007fc369a276f0 n/a (libcoreclr.so + 0x4276f0)

#11 0x00007fc369c3afb9 n/a (libcoreclr.so + 0x63afb9)

#12 0x00007fc36a69dd53 start_thread (libc.so.6 + 0x9dd53)

#13 0x00007fc36a72563c __clone3 (libc.so.6 + 0x12563c)

Stack trace of thread 29919:

#0 0x00007fc36a6a6922 __syscall_cancel_arch (libc.so.6 + 0xa6922)

#1 0x00007fc36a69a00c __internal_syscall_cancel (libc.so.6 + 0x9a00c)

#2 0x00007fc36a69a084 __syscall_cancel (libc.so.6 + 0x9a084)

#3 0x00007fc36a717537 __open (libc.so.6 + 0x117537)

#4 0x00007fc36987bbaf n/a (libcoreclr.so + 0x27bbaf)

#5 0x00007fc369876957 n/a (libcoreclr.so + 0x276957)

#6 0x00007fc369875a25 n/a (libcoreclr.so + 0x275a25)

#7 0x00007fc369c3afb9 n/a (libcoreclr.so + 0x63afb9)

#8 0x00007fc36a69dd53 start_thread (libc.so.6 + 0x9dd53)

#9 0x00007fc36a72563c __clone3 (libc.so.6 + 0x12563c)

ELF object binary architecture: AMD x86-64

2

Have you tried starting vscode from the terminal?

3

I have not, no Hadn’t even thought of that. I usually kick it off from a Hyprland launcher. Lemme try that.

4

Okay, I launched ‘code’ from terminal. didn’t see any logging in the terminal, it just came up as vscode always does. ran my build and got the same coredump, but didn’t see anything in the terminal

image
image3812×2112 356 KB

5

Just looked at the vscode invocation and it appears you can pass --verbose to it.

6

Yep, –verbose does work! a bit too well, its alot. Far too much to post here. Ill see if I can narrow down what it is telling me related to the crash. Thanks for now!

7

Are you using nix-ld? Which vscode package are you using? Please share relevant NixOS config.

Pastebin or github gist would work.

8

Okay, sounds good. Let me put that with my config files into a pastebin and post a link here. Thanks!

9

Here is the pastebin with the config files: configuration.nix{ config, pkgs, lib, ... }:let vars = import ./Gri - Pastebin.com

Here is the vscode_verbose.txt Dropbox

10

Can you share a bit more about your vscode setup?
Are you using an extension to build something for you (what are your extensions)? (Can you build it on cli but not with the extension?)
Can you share the build file?

11

So this is a Godot-Mono project. So yes, I am using VSCode to build the C# project and run the it on Godot-Mono so that I can debug it. It has been a pretty rock solid method of using Godot Mono with VSCode as Godot itself doesn’t support a debugger for C#. That said, I would not call myself an expecrt in extensions, I have more of an amature game dev so I just following the official docs in setting it up and it worked (on arch).

12

Should also add that I only have two extensions installed, both official MS extensions, C# Dev Kit and C# lang

image
image383×432 28.9 KB

13

I guess it is possible I just happened to luck into finding a bug in the extension from MS itself. I see it was release 3 weeks ago and isn’t the pre-release version, but who knows

image
image1389×714 107 KB

14

Also, if anyone was ambitious and wanted to really try to reproduce, and you had godot-mono and vscode working, there is the codebase, its opensource. https://codeberg.org/sazboom/MediaNocteOpen

15

Just to confirm I wasn’t doing anything strange in the build, I downloaded a blessed template from Godot with a C# build script for a dummy app and that one also coredumped. So my suspisions moved to the extensions from MS. I rolled the four I had back to a version 2 months old, retried the build of the template from Godot and that coredumped. Anyway, thats all the troubleshooting I can do for now. I’m considering rolling on back to arch with this machine for now until I can get a dev env tested and working on Nix. Thank you to everyone who suggested things to try!

16

i can’t reach your config.nix at the moment on pastebin.
Did you have a look here: Reddit - Please wait for verification

I will try it later.

17

I also couldn’t get it to work. I found this github issue: vsdbg not working in vscode · Issue #201137 · NixOS/nixpkgs · GitHub

18

I appreciate you trying. I would have replied earlier but apparently I talked too much and was thottled for a couple days in fear I was a bot, lol. Anyway, I opted to move back to Arch for now. Thanks again

19

maybe try => Visual Studio Code - Official NixOS Wiki