This flag causes the debug event to be replayed after the target thread
continues. It can be used, after suspending the thread, to resume other
threads and later return to the breaking.
This will help implementing gdb continue/step packets correctly.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
So that we can query the Unix symlink target from a file handle.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise, we may attempt to access freed memory trawling the device list.
This can occur if a device driver crashes during an IRP_CALL_CLOSE request.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise, the only thing holding a reference to a device may be a
device_file. If this is released in delete_device(), the subsequent call to
unlink_named_object() will crash. This can occur if a device driver crashes
with pending IRPs outstanding.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Whenever alloc_handle fails, we ignored the error and dequeued the
next APC. This patch makes the loop break whenever the error status
changes.
Note that the APC is still marked as executed although it failed.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It breaks too many things.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=48357
Signed-off-by: Damjan Jovanovic <damjan.jov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Repeated calls to WSAEventSelect() with FD_WRITE deliver
spurious FD_WRITE events, as the flag isn't held, resulting
in us unnecessarily polling the socket for writability,
despite the fact FD_WRITE should only be delivered (1) initially
on socket creation, and (2) after send[to]() fails with
EWOULDBLOCK and buffer space becomes available.
Signed-off-by: Damjan Jovanovic <damjan.jov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Inspired by a patch by Andrew Eikum.
macOS's mach_absolute_time() stops counting when the computer goes to
sleep/suspend/hibernate/etc. However, Windows's GetTickCount() does not
stop counting. mach_continuous_time() matches Windows's behavior.
BSD's CLOCK_MONOTONIC already counts asleep time.
Unfortunately, there is no clock source on Linux which does exactly what
we want. CLOCK_MONOTONIC_RAW is unaffected by NTP adjustment, but like
mach_absolute_time() doesn't keep ticking when the computer is asleep.
CLOCK_BOOTTIME does keep ticking, but it is affected by NTP adjustments.
CLOCK_MONOTONIC has both problems. What's needed is a
CLOCK_BOOTTIME_RAW, which would not be slewed by adjtimex(2) and would
count time spent asleep.
To avoid issues with skew and performance, this patch falls back to
mach_absolute_time() on macOS if mach_continuous_time() is unavailable.
Note that mach_continuous_time() was introduced in macOS 10.12, meaning
that if the minimum version required is less than that, it will be
linked weakly. Therefore we must check that it is nonnull before
attempting to call it.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Jacek Caban