Gili Hi Gili,

Thank you for this detailed report accompanied with a test case reproducing the problem. Which OS have you tested this on?

Also, is it correct to say that the semaphore is used to limit the number of concurrent threads to 5000?

Hi Ceki,

I've updated the Environment section of the bug report. I'm running under Windows 10.

Yes, the semaphore is used to limit the number of concurrent threads.

If you want to reproduce the bug even faster, you can make the following changes:

• Change maxFileSize to 1MB and totalSizeCap to 10MB in logback.xml
• Decrease the number of semaphore permits to 50

When I run this, I get a deadlock after a single line of output.

Thank you for the updates.

I have tried varying several parameters. In particular, it seems that when virtual threads are replaced with regular threads, then the test hums along for a long time without problems.

I also noticed that in case of a hang up with virtual threads, the thread dump provided by IDEA IntelliJ is near useless. The information provided by jstack does not seem much better.

From what I gathered thus far, the virtual threads get blocked when invoking a logger and never release the semaphore. This in turn causes the main thread to be blocked. Although the reason for the virtual threads getting blocked remains mysterious.

Run with -Djdk.tracePinnedThreads=full to see if it reveals anything, it might be that logback is using a mix of monitors and j.u.c locks and this leads to this issue.

Ceki,

I've never tried -Djdk.tracePinnedThreads=full as Alan mentioned but here is what worked for me:

• Run the test with "-Djdk.trackAllThreads=true"
• Once it hangs, run "jcmd <pid> Thread.dump_to_file <filename>" from a terminal

This will give you a thread dump containing virtual threads (unlike the old mechanism which only shows carrier threads).