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.)
- Create a file cache for FUSE mounted files on open to allow
memory mapping these files unless direct_io is specified.
- Implement DoIO for FUSE mounted files.
This patch enables files mounted through FUSE filesystems such as
sshfs or vmhgfs to be `mmap`ed, allowing remotely cross-compiled
executables to be directly run on Haiku.
Change-Id: I364b8225eae5b1d586280c2b3301fb661581caed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6277
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Use 0 as the magic value instead of a positive one. This way, <= 0
consistently signals that the callout is not in the list, whereas > 0
signals that it is.
* The old non-EGL OpenGL kit did some weird stuff (tm) trying
to fix Be's mistakes around OpenGL locking.
* The EGL libglvnd OpenGL kit (coming soon) no longer does wierd
unlocking behaviours. This fixes a "white screen" for Haiku3D
Change-Id: I2a6804098516c0cd9ec63ccd1eb25c0813452933
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6267
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Reorganize inner loop for clarity and to reduce indentation.
* Handle callouts that are due at this exact system_time.
* "break" instead of "continue" if lock fails.
BMessage contents are packed so we might get alignment exception on some
architectures when fetching fields from message with Find##typeName.
As memcpy() is already used when composing message content in AddData,
here we introduce memcpy in Find##typeName functions.
Change-Id: I0213409a219acda138f8d2fe7023e5dcfcd5cff3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6195
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Just some refactoring, nothing too much. The tooltip is not necessary
because the hints have been made much more visible using popups and
the default state of the Installer window itself.
Change-Id: I25f10fe3460c4df0bdc4e4af298532f94c65ebc5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6262
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
With the change in hrev56876, translator configuration views no longer
need to hint what their sizes should be.
Change-Id: I7742b4c8d71ec98635e530b34573e6f765f12d30
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6265
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
As far as I can tell, it has no consumers whatsoever outside the tree.
(wpa_supplicant did not even use it.) So, remove it altogether.
If that turns out to be mistaken, we can reinstate it temporarily
as a private class function or ABI-only symbol.
GetNextNetwork is very inefficient as it fetches all networks but only
returns one of them. GetNetworks was introduced to compensate for that,
but only the most regular consumers were initially migrated. Now,
the remaining consumers of the old API are converted to the new one.
The former will use the explicit preferred size if one is set;
otherwise, it will use the computed preferred size; whereas
the latter will only use the explicitly set one, which if it has
not been set, will just be an empty BRect.
Fixes#15434, #18329.
If callout_stop() runs at the same time the callout_thread is
about to process the callout, we can wind up with a situation where
the callout is "active" but has not yet run due to waiting on the mutex.
FreeBSD's documentation confirms that callout_stop must be called
(when "safe" is 0, i.e. not callout_drain) with the callout's lock
held, if it has one, and so we can prevent the callout from being
invoked at this point, too.
Additionally, fix return values of callout_reset.
May further help with #18315.
* TLS slots are not in any way architecture-specific; we do not even
have a mechanism by which they could be made so at present.
Thus, the initialization of them can be moved to common code, and
out of the per-architecture implementations.
* When dealing with a fork()ed thread, it will already have a TLS array
with values set in it. Therefore, do not overwrite the whole array,
but instead only update the specific values which have changed on fork.
This fixes at least part of #17896.
* Break in FlagsTypeHandler once we have cleared all flags.
* Use sizeof(hex) instead of writing out the size again.
* Place comment above variable name in patch_syscalls.
Our std::string is not broken; rather, the bytesRead may include the
terminating NULL byte, which was then added to the string and caused
misbehaviors. So we need to use strnlen with std::string also, and
then everything works as expected.
This way, we save 3 string comparisons on every non-empty return value.
Actually this code was broken before, and did not print error names
for return types other than status_t, because message.return_value
is an unsigned integer and thus "< 0" was always false. Now we cast
appropriately in the new TypeHandler, so this works properly.
Before, pressing Disk->Rescan would keep the previous item selected but
move the keyboard focus to the first element.
Change-Id: Iff99bff64bd67128834a1021dc63f1801ecb4c92
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6264
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Ensure that enough space is used for text
- Adjust string in Installer to fix weird wrapping issues
- Make Installer logos smaller
Change-Id: Ibd9cc9a944928263f28a43094b695f1018c30a5f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6187
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
- VNode names are now allowed to have a length of 1. This is
common for Windows drives mounted through a shared filesystem.
- Empty VNode names are now checked from the userland side,
preventing the kernel driver to reject and not ACK a false
B_OK from the userland server.
Change-Id: If0a6fcea1387367d1492c9b94c62c03e381ce1c1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6276
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Caused `open` to display an error with non-zero exit code when the
target application was already running and is single launch. In fact,
the error check at the end explicitly tests for B_ALREADY_RUNNING
along with B_OK.
Change-Id: Ic38c961bcdd8350b97b0d75ec010d25198afd561
From the FreeBSD manual pages:
> If the callout is currently being serviced and cannot be stopped,
> and at the same time a next invocation of the same callout is also
> scheduled, then callout_stop() unschedules the next run and returns
> zero.
Previously we would return zero but not unschedule the next run.
This may fix#18315.
Since we used a hash table with a fixed size (1024), collisions were
obviously inevitable, meaning that while insertions would always be
fast, lookups and deletions would take linear time to search the
linked-list for the area in question. For recently-created areas,
this would be fast; for less-recently-created areas, it would get
slower and slower and slower.
A particularly pathological case was the "mmap/24-1" test from the
Open POSIX Testsuite, which creates millions of areas until it hits
ENOMEM; it then simply exits, at which point it would run for minutes
and minutes in the kernel team deletion routines; how long I don't know,
as I rebooted before it finished.
This change fixes that problem, among others, at the cost of increased
area creation time, by using an AVL tree instead of a hash. For comparison,
mmap'ing 2 million areas with the "24-1" test before this change took
around 0m2.706s of real time, while afterwards it takes about 0m3.118s,
or around a 15% increase (1.152x).
On the other hand, the total test runtime for 2 million areas went from
around 2m11.050s to 0m4.035s, or around a 97% decrease (0.031x); in other
words, with this new code, it is *32 times faster.*
Area insertion will no longer be O(1), however, so the time increase
may go up with the number of areas present on the system; but if it's
only around 3 seconds to create 2 million areas, or about 1.56 us per area,
vs. 1.35 us before, I don't think that's worth worrying about.
My nonscientific "compile HaikuDepot with 2 cores in VM" benchmark
seems to be within the realm of "noise", anyway, with most results
both before and after this change coming in around 47s real time.
Change-Id: I230e17de4f80304d082152af83db8bd5abe7b831
* Remove comment stating DesktopColor is buggy. The documentation has
since been updated clarifying that this is the expected behavior.
* Refactor code.
* No functional changes.
Change-Id: I03711136eb613afb80ad8c03a7f18ba6d15f641c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6256
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* Clarify what information BWindow::WorkspacesChanged provides
* Clarify when BWindow::WorkspaceActivated is called
Change-Id: Ifcb041bcf67db1ee5c1c514a2b97baa49f8c4dcc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6257
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
