Re: [PATCH v5 0/1] MR1503: wineusb.sys: Move event handling to a single thread.

[Ivo Ivanov (＠logos128)]

> 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