Closed dkorpel closed 2 years ago
closing as duplicate of #185 as likely the issue, but feel free to reconfirm with 0.7.2 when released in a minute and reopen if needed.
VSCode auto-installed serve-d_0.7.3, and the issue looks gone!
Seems like I celebrated too early, I still have this issue :(
can you send updated stacktrace of all threads again?
It doesn't seem very easily reproducible the minimal test server I have for debugging this kind of issue also closes without issue.
(gdb) thread apply all bt
Thread 4 (Thread 0x7fa811d45700 (LWP 27402) "serve-d"):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x5570650d3688) at ../sysdeps/nptl/futex-internal.h:186
#1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5570650d3638, cond=0x5570650d3660) at pthread_cond_wait.c:508
#2 __pthread_cond_wait (cond=0x5570650d3660, mutex=0x5570650d3638) at pthread_cond_wait.c:638
#3 0x0000557063d09225 in core.sync.event.Event.wait(core.time.Duration) ()
#4 0x0000557063d030cc in core.internal.gc.impl.conservative.gc.Gcx.scanBackground() ()
#5 0x0000557063d098e4 in core.thread.osthread.createLowLevelThread(void() nothrow delegate, uint, void() nothrow delegate).thread_lowlevelEntry(void*) ()
#6 0x00007fa81319aea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007fa812f5bdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 3 (Thread 0x7fa811d4d700 (LWP 27401) "serve-d"):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x5570650d3688) at ../sysdeps/nptl/futex-internal.h:186
#1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5570650d3638, cond=0x5570650d3660) at pthread_cond_wait.c:508
--Type <RET> for more, q to quit, c to continue without paging--c
#2 __pthread_cond_wait (cond=0x5570650d3660, mutex=0x5570650d3638) at pthread_cond_wait.c:638
#3 0x0000557063d09225 in core.sync.event.Event.wait(core.time.Duration) ()
#4 0x0000557063d030cc in core.internal.gc.impl.conservative.gc.Gcx.scanBackground() ()
#5 0x0000557063d098e4 in core.thread.osthread.createLowLevelThread(void() nothrow delegate, uint, void() nothrow delegate).thread_lowlevelEntry(void*) ()
#6 0x00007fa81319aea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007fa812f5bdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 2 (Thread 0x7fa8131c1700 (LWP 27400) "serve-d"):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x5570650d3688) at ../sysdeps/nptl/futex-internal.h:186
#1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5570650d3638, cond=0x5570650d3660) at pthread_cond_wait.c:508
#2 __pthread_cond_wait (cond=0x5570650d3660, mutex=0x5570650d3638) at pthread_cond_wait.c:638
#3 0x0000557063d09225 in core.sync.event.Event.wait(core.time.Duration) ()
#4 0x0000557063d030cc in core.internal.gc.impl.conservative.gc.Gcx.scanBackground() ()
#5 0x0000557063d098e4 in core.thread.osthread.createLowLevelThread(void() nothrow delegate, uint, void() nothrow delegate).thread_lowlevelEntry(void*) ()
#6 0x00007fa81319aea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007fa812f5bdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 1 (Thread 0x7fa812e59780 (LWP 27392) "serve-d"):
#0 0x0000557063cfdb1c in core.internal.gc.impl.conservative.gc.ConservativeGC.qalloc(ulong, uint, scope const(TypeInfo)) ()
#1 0x0000557063c45197 in gc_qalloc ()
#2 0x0000557063cb3920 in rt.lifetime.__arrayAlloc(ulong, scope const(TypeInfo), const(TypeInfo)) ()
#3 0x0000557063c4f526 in _d_arrayliteralTX ()
#4 0x0000557063731bc0 in served.lsp.filereader.FileReader.yieldLine() (this=0x7fa812d7af00) at lsp/source/served/lsp/filereader.d:204
#5 0x0000557063737224 in served.lsp.jsonrpc.RPCProcessor.run() (this=0x7fa812dab370) at lsp/source/served/lsp/jsonrpc.d:255
#6 0x0000557063c48261 in core.thread.context.Callable.opCall() ()
#7 0x0000557063cb1874 in fiber_entryPoint ()
#8 0x0000000000000000 in ?? ()
This is with serve-d
set to a debug build from the master branch (dub build
), and after opening the repository of dlang/dmd in VSCode and closing it.
I can't reproduce it with dlang/dmd on my machine
With the backtrace you sent it also shouldn't max out any CPU (there is only 1 thread other than GC thread in your post and that thread is in "yieldLine" which calls Fiber.yield, where the scheduler will always Thread.sleep for 10ms on every yield)
The question is why it's stuck there. I have made a small patch at an attempt to fix this, (checkout master / 8128219c5dcab885488559dd8ca73d292212e758) but if that doesn't work you should add a breakpoint at FileReader.yieldLine (filereader.d:201) and PosixStdinReader.isReading (filereader.d:181) to see how it's stepping. A video would be nice if you can step through there.
Also do dub upgrade
before calling dub build
to make sure that dub actually fetched the specified dependency versions.
confirmed fixed (with other version reproducing) by Mali Laurent on Discord now.
Released a new version so you can try it out soon and it should be fixed.
So far I didn't stumble on this anymore, so I'm hopeful.
+1, I had a similar issue on my Linux laptop. Currently rocking serve-d-0.7.4 and the issue is gone
When I close VSCode or switch to a different workspace, an orphaned
serve-d
process stays active using 25% CPU (I have 4 cores). I'm on Debian Linux.This might be a duplicate of https://github.com/Pure-D/serve-d/issues/185
I changed my serve-d executable to one with debug symbols that I built with
dub
from master, attached gdb, and got this backtrace: