tcp_segment_header.advertised_window is 16 bits.
Previously, instead of using the maximum window, zero would be sent, thus
the partner wouldn't send anything.
fix#18337
Change-Id: Ibff98ee58b84bdf52527a7821648a5faf20c5589
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6359
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
The address of the variable should be taken instead of the
variable itself being casted to `void*`.
This fixes a rare segfault bug when any Haiku binary runs in
a `chroot`ed environment without a `/dev` mount.
Change-Id: I2fdacac62fadbcce8006bbf0a5350f6ec95133ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6377
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Return `B_ENTRY_NOT_FOUND` instead of -1 when `/dev/graphics`
is not found.
Otherwise, `app_server` would run into an infinite loop
while waiting `fCardFD` to equal `B_ENTRY_NOT_FOUND` in some
specific environments such as a `chroot` where `/dev` is missing.
Change-Id: Ice23a82f58811f1258c58826c2488ae5c5c29cee
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6376
Reviewed-by: X512 <danger_mail@list.ru>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Fix drawing issue with DrawTextControlBorder().
Update text control border and status bar border colors
to match BeOS R5 better.
Fixes#17889
Change-Id: I3eeb9898b538456aec751f9b57d19b9910506325
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6271
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Refactor so that ExpandoMenuBar and TeamMenu both call the menu item
TeamMenuItem::HandleMouseDown() method to do the actual work and then
send a message to cleanup.
Fixes#17761
Change-Id: I0e13e5fc6c90236936120ff0dda1246123576d37
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6311
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The condition variable that the load_image'ing thread is waiting on
is also owned by that same thread, so as soon as it wakes up, it
will soon return, thus destroying it. Under high load or other unlucky
scheduling conditions, it seems this could occur before the other thread
had even returned from the condition variable's NotifyAll.
Since team->loading_info is protected by the team lock, simply
acquire the team lock once more after being awoken and returning,
to synchronize and prevent this race.
Should fix#18352.
See #18351 for details on the specifications.
This is the same thing NetBSD does. BeOS R5 defined these values
differently than we did even before this commit, and it does not
seem to have caused problems then, so this should be fine.
While technically an ABI break, in practice these values are not
always differentiated on other platforms, and it appears musl's
code triggers divide-by-zero exceptions on purpose before it
returns this value, anyway.
Fixes#18351.
HDS has increased the length of the nickname to
32 characters on version 1.0.147 and this change
supports that change in the desktop client.
Resolves to #18343
Change-Id: Iae07acc165165e91b04cef7ebc1190d241d9a053
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6307
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
On a multi-level list view, when expanding an item containing other collapsed lists, the last items disappear due to a wrong element counting.
Change-Id: I2313ad8efb23e8db54cd3563687bf0c2a775a12a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6259
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Stefano Ceccherini <stefano.ceccherini@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
With the package kit merge, settings from packages were
placed into ~/config/settings/global for packages installed
into the PackageFS Home mount.
As a result, B_FIND_PATH_SETTINGS_DIRECTORY was returning a
user settings path different to the find directory API, making
transitioning from find directory to find path incompatible.
This change also updates the package_daemon and packagefs
to remove the remapping also occurring there.
Change-Id: Id5d077503e177a5f7cbc48779c132160b0d01890
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5941
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
'File -> Close and -> Set to' used a hard-coded window size and
control/button layout. Switch this to use the layout library for proper
scaling.
Change-Id: Ieeed93da82fb6bdcca852e3bb2f5a3315222ec27
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6303
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Note that this only affects the leaf and team menu item icon size
as we do not actually display any bold text here and this does not
cause any menu text to display as bold anywhere in Deskbar.
The reason to use bold font is because the leaf/team menu is set
to the same height as the window tab and the window tab is bold.
Fixes#17913
Change-Id: I8fd23e30e9a28e6aa24b4726c73863b9d0370010
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6297
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Automation <automation@haiku-os.org>
BitmapStream creates a BBitmap without specifying a bytes per row, but
then check the bytes per row matches the header. It is better to ask
BBitmap for the desired bytes per row to avoid any difference in
padding.
Change-Id: Ie1facfd423ad888a14757a0fffc9e8cdf72ef832
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6301
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The current version expects the first box to be exactly 32 bytes, but some
files found in the wild only have 28 bytes, so we now ignore the first four
bytes and it works.
Change-Id: I4c304bd6385bffd15f4adbb99cbf464f9767f7bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6302
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: nephele <nep@packageloss.eu>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Adds support for handling executable files in the
Debugger::RefsReceived function.
This change
* makes Deskbar menu->Recent Applications->Debugger->A recently opened
executable open the executable instead of simply opening the
Teams window, and
* allows dragging and dropping an executable onto the application's
icon.
Change-Id: I8e70e7929188301ce976f1f14e885236d3cb2b0a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6299
Reviewed-by: Rene Gollent <rene@gollent.com>
Tested-by: Automation <automation@haiku-os.org>
* Make some code common in Insert.
* Remove unneeded logic from InsertAfter and just call the base Insert.
InsertBefore does this, already.
* Synchronize Insert code and APIs in the fs_shell DoublyLinkedList.
Removing it outright would cause implicit conversions and then the other
variant being called, which would create invalid lists. So make it private
so that any attempts to use it will create errors at compile-time.
The Insert(before, element) function has been marked deprecated since
2010, but still had many usage and kept accumulating more. It's long
past time we got rid of all them and actually deprecated the function
itself.
Insert(before, element) just calls InsertBefore, so no functional change.
These caught the problem fixed in prior commits, and would have saved
me an awful lot of debugging time had they existed from the start.
They cannot catch all double-list-insertions, of course, but it's
relatively cheap to add these, and more than nothing.
* Create an internal variant which accepts a "bool locked" parameter.
Use this from callout_reset instead of invoking it before locking,
and then relocking afterwards. Eliminates some possible (though,
so far as I know, benign) races.
* mtx_assert always, even if the callout is not active. (Requirement
notated in the comment.)
* In callout_reset, do not invoke callout_stop at all unless we are
cancelling; in cases of mere reschedules, simply change c_due
and notify the callout thread.
* While at it, use list_init_etc in init_callout; no-op change,
but keeps things clean.
This should fix#18338 (specifically the change to never invoke
callout_stop when merely rescheduling, not cancelling.)
Here is the scenario in which this matters:
1. A callout comes due, it is removed from the list, and c_due is set
to 0. We then wind up in the mtx_lock here inside invoke_callout;
while some other thread holds the lock.
2. The other thread, holding the lock, decides to *re*schedule the callout
for a later time than the present. callout_reset sees the callout has
a c_due of 0, thus indicating it is not in the sTimers list, adds it,
and sets a (future) c_due.
3. The other thread unlocks c_mtx, thus the callout thread acquires it
and proceeds.
Under the code I wrote in hrev56875, before this commit, the following
would occur (at least with the ipro1000 driver on some hardware):
4. c_due would be set to -1, thus signaling the callout was no longer
scheduled, and thus not in the sTimers list (despite being in it!).
The callout's own method would decide to reschedule itself, and
invoke callout_reset as such.
5. callout_reset would, seeing c_due of <= 0, try to add the callout to
the sTimers list. However it is already in the list, and in many
circumstances the only item in the list, so it would get silently
linked to itself.
6. An infinite loop due to the looped linked-list and/or double-remove
resulting in NULL dereferences would result.
Steps 1-2 coinciding in just the right way was apparently very rare, hence
why this problem only appeared very infrequently. The code I wrote to force
their coinciding made the problem happen extremely frequently.
This fixes#18334.
(Figuring out that the problem was an item being linked to itself, and
most critically a double-*reschedule* not a double-*removal*, took
far too long to figure out. I will be refactoring this code more
in subsequent commits, but also introducing new assertions to our
linked-list systems which enabled me to finally track down this problem
at all. Who knows; perhaps they will shake loose other bugs.)
