Crash on TLS destructor call after libd3d12core.so has already been unloaded

[kasper93]

Windows Version

Microsoft Windows [Version 10.0.22631.4169]

WSL Version

2.3.24.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

Linux version 5.15.153.1-microsoft-standard-WSL2 (root@941d701f84f1)

Distro Version

Debian

Other Software

OpenGL / mpv

Repro Steps

1. mpv --no-config <video>
2. Close with q key

Expected Behavior

Doesn't crash on exit.

Actual Behavior

* thread #42, name = 'vo', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x7ffec043ab10)
  * frame #0: 0x00007ffec043ab10
    frame #1: 0x00007ffff3269801 libc.so.6`__GI___nptl_deallocate_tsd [inlined] __GI___nptl_deallocate_tsd at nptl_deallocate_tsd.c:73:29
    frame #2: 0x00007ffff3269786 libc.so.6`__GI___nptl_deallocate_tsd at nptl_deallocate_tsd.c:22:1
    frame #3: 0x00007ffff326c52f libc.so.6`start_thread(arg=<unavailable>) at pthread_create.c:455:3
    frame #4: 0x00007ffff32e72b8 libc.so.6`__clone3 at clone3.S:78

After comparing the memory map before closing, the address we are trying to call 0x00007ffec043ab10 is inside /usr/lib/wsl/lib/libd3d12core.so. However, by the time libc tries to clean it up, libd3d12core.so has already been unloaded. As expected, adding a dummy dlopen("/usr/lib/wsl/lib/libd3d12core.so", RTLD_LAZY | RTLD_GLOBAL) to prevent it from being unloaded works around the crash.

I didn't look into exactly how libd3d12core.so is loaded/unloaded. It is likely handled somewhere in the OpenGL driver. However, it's clear that the pthread_key_delete() call is missing before it gets unloaded. And when libc tries to clean outstanding keys it's already too late.

Diagnostic Logs

no more logs is required to understand the issue...

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Closed similar issues:

• Driver segmentation fault when closing sfml window (#10608), similarity score: 0.72

Note: You can give me feedback by thumbs upping or thumbs downing this comment.