The AllocatorTest suite fails, and when investigating why it was
broken I realized that it was testing code that has been dead and
unused for quite some time. makeudfimage hasn't been touched since
2004 (5f2185ea0), and was removed from the build in 2006 (5adca30a1).
The only changes that have been made to it since then are build fixes
for the tests. Adding it back to the build would require some work
since many things have changed since then.
Since there are many other tools and libraries out there which can
make UDF images (and which have been ported to Haiku), this code
doesn't really seem worth maintaining at this point.
This patch just removes it, as well as the associated tests.
Change-Id: I23da8df83b7f141b3394a022030545d42a287881
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2332
Reviewed-by: Adrien Destugues <[email protected]>
* Delete/free as appropriate
Most cases involve not freeing memory after encountering error or
unexpected situation (identified via cppcheck static analysis)
Change-Id: I90ba2fca518b00d2dfa9ec1ddbcebe1920a34b7c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1038
Reviewed-by: waddlesplash <[email protected]>
- Remove duplicate and otherwise unused lendian_bitfield.h
- Adjust listusb jamfile to use lendian_bitfield.h
- Fix various typos in usb_video.h and restore some fields to make
listusb happy
So many Jamfiles to search through...runs also, but there
are lots of graphical glitches
Change-Id: Ibf9e64566a5b8c5742792ac9b1b0f9ccc6693c8d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1753
Reviewed-by: waddlesplash <[email protected]>
Ignore unknown fields (also called attributes) which are from a package
file with a different minor version number. Previously it would halt
with an error when encountering such a field, even though it can safely
be skipped over (if it was unsafe, we would have incremented the major
version number).
The use case is a future package attribute for pre-uninstall scripts.
If they're not run, that just leaves some debris after uninstalling
(like symbolic link desktop icons).
* Use the B_NOT_SUPPORTED error code when reading unknown package
attributes. Don't treat it as an error if the package is a
different minor version, just skip it.
* Print unknown package attribute index numbers rather than stopping,
since they may be from future package file formats and can be safely
skipped otherwise. Mention the relevant enum so you can find it in
the source code. It's a pity that the previous abstraction layer
isn't present, since it tells us what data type the attribute is
(string, number, etc), so we could have printed its value too.
First step of two for enhancement #13427
See https://review.haiku-os.org/c/haiku/+/1504 to generate packages
with a different minor version number (second step of the enhancement).
Change-Id: I6db1897824a1713b3d5fab6fdfb990ee5923cd52
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1714
Reviewed-by: waddlesplash <[email protected]>
Consider this scenario:
* A userland thread puts its ID into some structure so that it
can be woken up later, sets its wait_status to initiate the
begin of the wait, and then calls _user_block_thread.
* A second thread finishes whatever task the first thread
intended to wait for, reads the ID almost immediately
after it was written, and calls _user_unblock_thread.
* _user_unblock_thread was called so soon that the first
thread is not yet blocked on the _user_block_thread block,
but is instead blocked on e.g. the thread's main mutex.
* The first thread's thread_block() call returns B_OK.
As in this example it was inside mutex_lock, it thinks
that it now owns the mutex.
* But it doesn't own the mutex, and so (until yesterday)
all sorts of mayhem and then a random crash occurs, or
(after yesterday) an assert-failure is tripped that
the thread does not own the mutex it expected to.
The above scenario is not a hypothetical, but is in fact the
exact scenario behind the strange panics in #15211.
The solution is to only have _user_unblock_thread actually
unblock threads that were blocked by _user_block_thread,
so I've introduced a new BLOCK_TYPE to differentiate these.
While I'm at it, remove the BLOCK_TYPE_USER_BASE, which was
never used (and now never will be.) If we want to differentiate
different consumers of _user_block_thread for debugging
purposes, we should use the currently-unused "object"
argument to thread_block, instead of cluttering the
relatively-clean block type debugging code with special
types.
One final note: The race condition which was the case of
this bug does not, in fact, imply a deadlock on the part
of the rw_lock here. The wait_status is protected by the
thread's mutex, which is acquired by both _user_block_thread
and _user_unblock_thread, and so if _user_unblock_thread
succeeds faster than _user_block_thread can initiate
the block, it will just see that wait_status is already
<= 0 and return immediately.
Fixes#15211.
Unless __STRICT_ANSI__ is defined (as it is when running the compiler in
--std=c89 or --std=c99, but not when running it without any specific
args), we can enable these by default and behave like most other
systems. I don't know why no one has done this yet despite suggesting it
multiple times and people prefer to #define _BSD_SOURCE manually
everywhere.
Remove all places in our Jamfiles and sources where it had been defined.
_DEFAULT_SOURCE is now enabled by default for all sources of Haiku, since we
let the compiler use GNU extensions (no strict C standard specified on
command line)
Use _DEFAULT_SOURCE as the define name to match current versions of
glibc. Enable it if _BSD_SOURCE is #defined in compiler flags, for
backward compatibility.
Change-Id: I6db04da5f6db437723cdfba3478f5094a69d7727
Reviewed-on: https://review.haiku-os.org/c/1633
Reviewed-by: Jérôme Duval <[email protected]>
If an overflow occurs before the cast, we can't fix it. If we cast
first, we can rely on integer promotion to make the result use the
appropriate size.
Change-Id: I7462e28422456c07f179f94d39c10c408d9bec36
Reviewed-on: https://review.haiku-os.org/c/1623
Reviewed-by: waddlesplash <[email protected]>
The USB3 specification changed the meaning of this field, and
it means different things depending on whether a USB 2 or 3
device is attached, so just don't print it.
Fixes listusb saying "Fullspeed" for USB3 devices. The per-device
information already prints what USB version and protocol the
device is operating on, so this was redundant anyway.
All of Barrett's individual reverts have been squashed into this
one commit, save a few actual bugfixes.
Change-Id: Ib0a7d0a841d3ac40b1fca7372c58b7f9229bd1f0
This makes the output much easier to read (e.g. "write(...)" vs.
"_kern_write(...)") and similar to strace/dtrace/etc. output
on other platforms.
Change-Id: Iac8e32aae0dcf3731a348c6192203f8d5b54da7a
Reviewed-on: https://review.haiku-os.org/c/1451
Reviewed-by: Bruno Albuquerque <[email protected]>
* Modeled after pppconfig to some degree.
* Normally various VPN and other services will create / manage
tunnels directly, however this gives us a good way to
test / play with things initially.
Kyle Ambroff-Kao