each poll_fd struct should be checked, valid when not -1 and revents not zero.
Change-Id: Ia624ad1369ad1a6066c9970a47cfac63fa773702
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4821
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
the socket interface module checks the receive.low_water_mark to automatically
notify a read event. available_data will be zero, thus enabling the notification.
fixes the test poll_nm in NSPR.
Change-Id: I5354faec439df96671506550cdb144a45f6082b1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4820
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
PulkoMandy in cb3199681e changed
the _GetDomainSupport functions to always Ref() the the object.
However, that means in the case of the second _GetDomainSupport
function, which is implemented in terms of the first, we should
not call Ref() as this will create a double-reference.
Fixes a memory leak.
Change-Id: Ib82b2dadc0c8cc8d8f95efcffeb2430ac602a0a9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4791
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
LGTM seems to provide GCC 9.2, for which the flag -Wformat-diag is falsely
detected as supported.
Change-Id: I95a5946d9c6cd2af73e85070973f855fba3fcc39
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4786
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
LGTM build failed since -Wformat-diag check is failed.
So we add g++ to check its version in LGTM.
May help to fix#17460.
Change-Id: I9400dbbab7800c522bf7ed797adae48299581a4e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4780
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* Working under qemu smp 1,2+
* Working on SiFive Unmatched
* x86_64 efi not broken by smp_boot_other_cpus change
Change-Id: I32ebc17913e46ed082be9ade8f56448bbf12f16e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4705
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Using a memcpy here is supremely dangerous, because we are writing to
an app_server buffer that we chose the length for, but using a size
that came from the client. And, indeed, because the buffer can contain
padding if the BBitmap was allocated with a non-standard BytesPerRow,
we will overflow the buffer and corrupt memory, causing app_server to crash.
So, instead, reorganize parameters a bit, and pass BytesPerRow along
with the other data needed to instantiate the bitmap, and then use
ImportBits.
Fixes an app_server crash I triggered with the experimental libX11
compatibility layer.
* Cut extra calls to display_get_encoder_mode
* Correct incorrect ucMiscInfo on table 1.6 via atombios
comments
Change-Id: Ib6d7938269b8421d3711c1344eab0b9842336932
* Looks like some error in atombios. AMD just
reversed the values instead of fixing the atom.h
defines in Linux.
Change-Id: I440682af5708ce0da1625e8f50e8cb77595c8397
* A first attempt at improving on #17377
* We haven't actually seen any cards using this
routing stuff yet pre-navi.
* We don't use the router information yet... but this might
improve things a bit on new cards.
Change-Id: I17962dfd8bb09e619a6084cd9571ccb9832fb19a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4697
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: If7feffafea4fc6d295d04f696127c8f0fbd8fb9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4704
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The previous round of this code unblocked after unset universally,
but that was incorrect in the case where the thread was not in
the "waiting" state before we unset. Yesterday I changed that to
just unblock before unset universally.
It seems, however, that thread_unblock is so time-consuming
that the other thread will wake up and begin doing things
before unblock returns for us, and then it will hit the timeout
before we have a chance to unset. So, now we unblock later
if it is possible to do so.
It seems very strange, though, that thread_unblock will
not return in a small but significant number of cases
before the unblocked thread actually starts running (note
that we are in interrupts-disabled mode here, so that is
not the problem.) That sounds like a problem for another day.
Should fix#17455, possibly in tandem with the previous commit.
This also fixes a leak of slots when initializing devices failed.
Fixes#16323, although there is some other underlying problem
which led to that error in the first place.
It is defined as a uint32:1, which apparently becomes an "int" on
newer GCC versions, which thus triggers a -Werror=format. So,
convert it explicitly in order to prevent the error.
In GCC 8 builds it is by default, in GCC 11 builds it is weakly
defined, which runtime_loader does not yet support properly,
so we force it to be included.
Unblocking after unsetting fVariable just causes too many headaches
and corner cases to deal with; the code as-is did not actually handle
all of them, as it missed the case where the entry thread had called
thread_prepare_to_block but had not yet actually blocked.
Hopefully the last fix for #17444.
