https://bugs.winehq.org/show_bug.cgi?id=38908
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Regression SHA1| |350ee62ab4ea40904296dcf90cf | |052938ca4ae75
--- Comment #2 from Anastasius Focht focht@gmx.net --- Hello Sebastian,
yes, it's that commit.
I only reverted the 'device_file_ops' part of it for faster rebuild/test.
--- snip --- $ git diff diff --git a/server/device.c b/server/device.c index e8ef832..c4954d4 100644 --- a/server/device.c +++ b/server/device.c @@ -198,7 +198,7 @@ static const struct object_ops device_file_ops = default_set_sd, /* set_sd */ no_lookup_name, /* lookup_name */ no_open_file, /* open_file */ - device_file_close_handle, /* close_handle */ + no_close_handle, /* close_handle */ device_file_destroy /* destroy */ }; --- snip ---
--- quote --- Most likely we should store the client_{pid,tid} directly in the irp structure, and client_tid is NULL then? --- quote ---
How would that be useful? As you said - at the time of process handle table destruction the process and all its associated threads are already dead ('current' = non-referenceable).
The "close handle" IRP is dispatched to a device manager thread ('mountmanager' in this case) and ought to be fulfilled there.
Unfortunately the device request "ping-pong" can't work here, there is no client to "reply" anymore.
Regards