Now vaguely follows the tree structure of "src", with the exception of
directories that described subsystems spanning more than one "kit" or
"server" (e.g. "media", "midi", "bluetooth") -- these have been left as their
own top-level directory within docs/develop.
This is the beginning of a large "move developer docs from the wiki
to the tree" operation, which will probably take some time to complete.
The general goal is to consolidate all docs that would be used by developers
(i.e., anyone working on the Haiku tree) into the tree itself. Docs on
getting started contributing, or for translators, designers, etc. will remain
on Trac and on the website.
PlaylistTrackCount returns the number of tracks in Playlist,
and PlaylistTrackTitle the title of a numbered track.
Also, remove B_TRANSLATE macros in scripting properties
when compiled in kernel mode, BMemoryIO::WriteAt() and BBufferDataReader::ReadData()
now check the buffer to write to, and eventually call user_memcpy() instead of memcpy().
* avoid assignment in if statements
* use boolean conditions
* use copy_from_user_value/copy_to_user_value instead of user_memcpy
* no functional changes except user buffer addresses check in:
_user_get_next_disk_device_id(), _user_get_disk_system_info(),
_user_get_next_disk_system_info(), _user_find_disk_system()
* remove TODO "Add user address checks and check return values of user_memcpy()!".
The scheduler uses the load tracking logic to compute the load of
threads to be enqueued into the run queue. The time delta between the
last enqueue and the next enqueue may grow very large for threads
that mostly wait on conditions. In such cases the int "n" period count
variable would become too small and wrap around, leading to an
assertion failure.
For this to happen, the thread in question would have to have slept for
at least ~25 days and then wake up. Threads often affected would be ones
waiting for some other process to end, for example shell threads waiting
for a long running process to exit.
Fixes#13558.
In the kernel and command-line tool, don't leak allocated memory,
even if the tool returns an error.
In the command-line tool, also handle memory allocation errors
nicely by giving the user an OOM message if allocation fails.
Fixes CID 1425367 and 1425224.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
It appears as if there is a typo in printf_size.c; it makes
no sense to compare an unitialized variable in such a way.
Since `info->width` is referenced later on in the variable
assignment, it seems possible that the intended statement
was to place the larger of the values between `info->width`
and `info->prec` into `width`.
Fixes CID 609431.
korli: Patch applied in cddfcf2f87
was incomplete. This patch completes with what upstream did in 2004:
fa5753eede.patch
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
Previously dead teams were always returned (as needed for wait/waitpid).
Using waitid it should however be possible to omit the WEXITED flag to
only get stopped (WUNTRACED | WSTOPPED) or continued (WCONTINUED) teams.
Adjust the other caller of the _kern_wait_for_child syscall, used by the
various less specific wait* functions, to always include WEXITED. This
avoids having to special case waitid in the syscall interface or with an
extra flag.
Add a check to ensure that any of these flags is set to avoid the now
possible case of nothing being specified. This fails with B_BAD_VALUE
(EINVAL) as on other systems.
On other systems their values are usually aliased. We defined them as
two different values, but didn't handle WSTOPPED anywhere. The check
is now simply extended to cover both bits.
When wait_for_child was called with a child argument equal to the
current team, the team was locked again to check if it was a child of
itself.
This is now handled the same way as on other systems, where this case
results in ECHILD (and not EINVAL).
DwarfImageDebugInfo:
- Type name/info entries weren't being freed properly.
BaseUnit:
- The array of entries itself was being destroyed, but not the actual
objects. Consequently none of the DIE objects were ever being freed.
CfaRuleSet:
- The register rules array wasn't being freed.
FileManager:
- References to entries weren't being released. Some more work remains to be
done here though, as a subset of these objects still have a non-zero ref
count in the end.
Following recent changes to use libroot_build on Haiku also, it is now
actually impossible to build Haiku components on non-Haiku platforms
(BeOS R5, Dan0, BONE, Zeta), so we can remove any logic related to this.
This is only the first part; still to be removed are:
* SetSubDirSupportedPlatformsBeOSCompatible
* HOST_PLATFORM_BEOS_COMPATIBLE
* TARGET_PLATFORM_BEOS_COMPATIBLE
It was discussed and introduced based on docs that some systems
need this to shutdown properly. I can find no mention of this in
ACPICA or ACPI docs.
This needs to be re-evalutad, as all my shutdowns been successful
after disabling it and I can't locate where this info came from
or if it actually helped.
See 1316462ab0 for original commit
and bug 12306 on current shutdown issue.
As it turns out, using the xattr emulation layer plus "libgnu"
causes some strange mixups at package build time, and so packages
built with it were winding up with no attributes at all.
So I've just bitten the bullet and written a full passthrough layer
to the system attributes. Verified using a full build of haiku.hpkg
this time ... after a lot of painful debugging of symlink mixups.
Hopefully I am finally rid of this plague...
* The global lock, needed for hw <-> os to sync, was a no op.
This means that OS and HW could read and write to same value
at the same time, causing garbled data and crashes. This is easiest
to see in battery status, where battery values and OEM name would
become garbage. It also causes instability and failure to shutdown
* ACPI used 64 bit addressing (which it normally should) on 32 bit.
This would cause page faults as it would jump to incorrect addresses
To quote jscipione (from 95e8362c52),
"Let me tell you a story about a bug" -- though this tale spans a much
lesser time than that one did.
In 5e19679ea3, I enabled libroot_build for
Haiku, instead of using the system libroot as we had before. There were
a number of bugs introduced along with this that I hadn't fixed (and there
may be more after this), but most of the obvious ones (crashes on x86_64...)
were fixed shortly enough.
Attribute usage, though, was a different story. Unlike most of the POSIX
calls in libroot, which were aliasing system functions no matter what the
platform, the attribute calls were not, as they are specific to Haiku.
Initially I had completely forgot about them, and it wasn't until a few days
later when I noticed that I had an "attributes" directory in my generated
that I realized that the "generic" attribute layer was being used on Haiku.
I attempted a fix for this in 5e19679ea3,
thinking that would clear the problem up, but I didn't actually run a test
beyond seeing that my BuildConfig had been updated properly. In fact,
BuildSetup was hard-wired to not even pass that definition through on
Haiku, and so that commit had in effect caused nothing.
My initial "fix" of just changing BuildSetup then caused a build failure,
as while libroot_build itself compiled, it ran into errors whenever attributes
were used, because in letting the real libroot's attribute calls shine
through, I had bypassed libroot_build's FD emulation/shim layer.
Then I tried and failed at three separate attempts to solve this with code:
- a version of the "fs_attr_...h" interface for Haiku. This proved possible
in theory, but in practice I would need to reimplement a lot of attribute
handling code in it, because all I had access to from there was syscalls.
- a version of "fs_attr_untyped" that bypassed its reimplementations of
the "fs*attr" functions for the libroot ones, only using the FD shim layer.
This proved possibly not even theoretically possible because it would have
caused preprocessor hell in some of the build headers, and also assumptions
about how attributes are read were totally different.
- a completely new "fs_attr_haiku" that was a completely new interface to
the fs*attr functions. This proved practically impossible because of the
need to include structures from the system libroot to call out to readdir,
etc. that attempts to solve would also have caused preprocessor hell.
Then I realized that the Linux xattr emulation library, which I'd used
as a reference when attempting the first solution, was shipped by default
as a system library in all builds of Haiku ... and so I could just tell
fs_attr_untyped to use the Linux xattr handler, and then link against libgnu.
So that is how I arrived at this strange and decidedly unorthodox solution
to a problem of my own creation.
Per #10267, "Most (ported) third-party software should be removed
from the Haiku source repository."
Since HaikuPorts already has the ncompress package, this file
should no longer exist.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Original patch missed modifying the "minimum" definition and the
src/bin/Jamfile, so I took care of that.
In MediaPlay.cpp, media_play returns non-zero value on failure but forgets to return zero on success.
Coverity CID: 1422617
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
set_var doesn't return any value yet its return type is ULONG, and Coverity freaks out about that. This patch turns that function into a void function.
Coverity CID: 603433
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
TeamWindow:
- Properly delete stack frame selection entries in destructor.
TeamDebugger:
- The reference to TeamDebugInfo wasn't correctly initialized to own,
leading to TeamDebugInfo never being destroyed.
FunctionInstance:
- Also clear source code reference in destructor.
ImageDebugInfo:
- Release references to specific infos in destructor. These are acquired
on our behalf when loading the image info, but were never released,
leading to the latter never being freed.
DwarfManager:
- Release references to files in destructor.
FileManager:
- Release entries in various destructors.
Somewhat improves the situation in #13800, but is still far from complete,
as a thorough review of this nature hasn't ever really been done.
TeamDebugger:
- In several cases, BReferences on thread handlers after a call to
_GetThreadHandler() weren't correctly initialized to account for
that function implicitly acquiring a reference on our behalf, leading
to the reference count to spiral out of control, and consequently the
handler would never be freed. Found while attempting to address
#13800, likely more to come.
- Recent changes to the build system appear to make the assumption
that the GNU regex APIs are universally available. This isn't the
case on FreeBSD, which requires libgnuregex to provide that
functionality. This broke the host keymap build.
Augustin Cavalier