> Wouldn't we normally be in libusb_handle_events() at this point? I guess there's just differences between different call stacks?
Yes, it is polling in the libusb_event thread at this point. The actual segfault happens in the wineusb client thread, where it is waiting in pthread_cond_wait(). I tried to debug this several times, but the call stack was obviously wrong, so I couldn't figure out what was raising the signal. All other threads exit normally, with the libusb_event thread last. Here is a small analysis I did with gdb: [winedevice_sigsegv.log](/uploads/6cd9ecc4c4d6fd798c402079b067d77f/winedevice_sigsegv.log)
The first part of the log is the actual core dump. The second part includes a gdb session with the problematic winedevice.exe, where all threads are initially described by their call stacks, and then execution continues to the end.
> I don't think we should be terminating threads at all. It appears that comes from 7f749d58d, but we should probably just figure out what's keeping those threads alive and give them a chance to shut down naturally, adjusting timeouts if necessary.
I think there was an effort https://gitlab.winehq.org/wine/wine/-/merge_requests/1088 to fix this in general, which has been put on hold for now.
> That's all orthogonal to this change, though, or at least, I think it makes sense regardless of bug 52213, since it simplifies the code.
I agree. I should have put the emphasis on the new implementation. But then again my main motivation to implement this was to fix the crash.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1503#note_17798
> (The TlsIndex field in the LDR_DATA_TABLE_ENTRY structure appears to be unused except as a flag that the module has TLS (being always set to -1), at least as far back as Windows XP. It is worth mentioning that the WINE implementation of implicit TLS incorrectly uses TlsIndex as the real module TLS index, so it may be unreliable to assume that it is always -1 if you care about working on WINE.)
>
> \- http://www.nynaeve.net/?p=186
and the "links to that article but still doesn't work in wine" award goes to... [the D runtime](https://github.com/dlang/dmd/blob/6bf60ea0eb174631ede0074a77d3898d…! (Admittedly, there aren't too many ways to do what they're trying to do.)
With this, the D runtime will now work in Wine, even if in a dll loaded into an exe with no tls (which gets it the tls index 0)
The changes to the debugger are a bit icky, a possible alternative is to find some other easily-debugger-accessible place to stuff the tls index.
--
v3: ntdll: TlsIndex should not actually contain tls indices
https://gitlab.winehq.org/wine/wine/-/merge_requests/1578
> (The TlsIndex field in the LDR_DATA_TABLE_ENTRY structure appears to be unused except as a flag that the module has TLS (being always set to -1), at least as far back as Windows XP. It is worth mentioning that the WINE implementation of implicit TLS incorrectly uses TlsIndex as the real module TLS index, so it may be unreliable to assume that it is always -1 if you care about working on WINE.)
>
> \- http://www.nynaeve.net/?p=186
and the "links to that article but still doesn't work in wine" award goes to... [the D runtime](https://github.com/dlang/dmd/blob/6bf60ea0eb174631ede0074a77d3898d…! (Admittedly, there aren't too many ways to do what they're trying to do.)
With this, the D runtime will now work in Wine, even if in a dll loaded into an exe with no tls (which gets it the tls index 0)
The changes to the debugger are a bit icky, a possible alternative is to find some other easily-debugger-accessible place to stuff the tls index.
--
v2: ntdll: TlsIndex should not actually contain tls indices
https://gitlab.winehq.org/wine/wine/-/merge_requests/1578