[Bug 51573] New: winedevice.exe crashes in libusb_close() on exit

WineHQ Bugzilla wine-bugs at winehq.org
Sat Aug 7 08:03:10 CDT 2021


https://bugs.winehq.org/show_bug.cgi?id=51573

            Bug ID: 51573
           Summary: winedevice.exe crashes in libusb_close() on exit
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: usb
          Assignee: wine-bugs at winehq.org
          Reporter: fgouget at codeweavers.com
      Distribution: ---

On my box winedevice.exe systematically crashes on exit:

$ ./wine hostname.exe /?
INTEL-MESA: warning: Haswell Vulkan support is incomplete
Usage : hostname
$ wine: Unhandled page fault on write access to 00000000 at address 7E95C4D1
(thread 0070), starting debugger...
0070:err:seh:start_debugger Couldn't start debugger L"winedbg --auto 96 64"
(1115)
Read the Wine Developers Guide on how to set up winedbg or another debugger

winedbg.exe is not really usable because it prevents Wine from shutting down
and winedevice.exe from exiting. But tracing showed that the crash happens in
the libusb_close() call of fdo_pnp() in dlls/wineusb.sys/wineusb.c:

https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/wineusb.sys/wineusb.c#l262


This is with Debian's version 2:1.0.22-2 of the libusb-1.0-0 and
libusb-1.0-0-dev packages.

All I found online is that libusb_close() typically crashes when there are
control transfers still in progress. So maybe this is a cleanup issue?


Finally the crash started with this commit. Could it be related to the
potential cleanup issue mentioned above?

commit b065daa600e858823944f996144ed233065da7fd
Author: Rémi Bernon <rbernon at codeweavers.com>
Date:   Tue Jul 6 11:00:47 2021 +0200

    ntoskrnl.exe: Send IRP_MN_SURPRISE_REMOVAL to the device stack first.

    Instead of sending both IRP_MN_SURPRISE_REMOVAL and IRP_MN_REMOVE_DEVICE
    to all children first.

    They may have pending IRPs sent to their parent PDO driver, which need
    to be cancelled before IRP_MN_REMOVE_DEVICE can complete. This is the
    case for hidclass.sys and its thread calling the lower driver for
    instance.

    Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
    Signed-off-by: Zebediah Figura <zfigura at codeweavers.com>
    Signed-off-by: Alexandre Julliard <julliard at winehq.org>

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.


More information about the wine-bugs mailing list