FreeBSD 14-CURRENT got the non-standard sched_setaffinity() function, but
it uses FreeBSD's cpuset_t type instead of Linux's cpu_set_t (also
non-standard). This breaks the build. We have to define _WITH_CPU_SET_T
before including <sched.h> to get that type named cpu_set_t instead.
Signed-off-by: Damjan Jovanovic <damjan.jov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a regression introduced by 97afac469f.
If we make a request on an asynchronous device handle, and the IRP handler
returns STATUS_PENDING, wait_async() will return STATUS_PENDING, as intended.
However, if the async object is signaled before the user has a chance to call
wait_async() [e.g. if get_next_device_request is called quickly enough], select
will return STATUS_PENDING immediately, which causes server_select() to think
the object is not signaled, and wait for a select reply forever.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51277
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51295
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Steam uses WSASend() with completion ports, reusing OVERLAPPED structures as
soon as they are returned from GetQueuedCompletionStatus(). Since completion is
queued during the select request in wait_async(), the I/O status block can be
reused even before the call to NtDeviceIoControl exits.
This works fine with current Wine, because WSASend() doesn't access the I/O
status block after queuing completion. However, a patch that changes it to use
wait_async() like other async requests causes NtDeviceIoControlFile to
consistently return garbage status codes.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Largely based on a patch by Nikolay Sivov for NtGetNextProcess().
Signed-off-by: Paul Gofman <pgofman@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As some thread may use a different desktop from their process.
This fixes the user32 win tests, which leaks a desktop that never gets
closed. The test_shell_window test creates a new desktop, which spawns
explorer.exe process, incrementing the desktop user count to 1, then
associates the desktop to a thread, which closes it on exit.
Never the user count is incremented to 2, and closing the thread desktop
doesn't either check whether the desktop process should be terminated.
Reversely, it is possible to create a desktop, associate it with a
thread /and/ a process, and this time the desktop process would be
terminated when the process exits, although the thread may still be
using it.
Tracking the users per thread is more robust and fixes the problem as
set_thread_desktop increments the desktop user count, and thread exit
decrements it.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
WoW64 process has two separate contexts:
- x86 context used most of the time (e.g. by application code)
- x86_64 context used by system when it quits x86 emulation and jumps to
the kernel code
A notable exception are debug registers - their state is shared. Some
debuggers make use of that fact and sets/gets debug registers of x86
processes using x86_64 thread context.
Add support for setting and getting debug registers using x86_64
thread context. Getting other registers is allowed too and will return
values from x86 thread context.
Fixes hardware breakpoints in IDA 7.0 disassembler (x86_64 app) when
debugging x86 (32 bit) applications.
Signed-off-by: Rafał Harabień <rafalh92@outlook.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
I've left another case of returning STATUS_PROCESS_IS_TERMINATING since
that's not covered by the tests.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50704
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This can happen if the async is terminated while there is no thread to queue
the APC to (as in the relevant test), or if the client dies before getting the
APC, or before transferring the APC results back to the server.
This also fixes a leak of async objects present since 61abc500f5. If a process
dies while accept asyncs are pending, the asyncs will be terminated but will
not find a valid thread to queue the APC to, and thus async_set_result() and
the completion callback are never called.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
