The actual xfreopen function is only relevant if O_BINARY != 0 and all
places invoking it are surrounded by if statements that are always
false if O_BINARY == 0. The compiler therefore stripped all the calls
out at the default -O2, but this obviously breaks down with DEBUG on.
The variable is used in the TRACE(), but that is only enabled for
DEBUG >= 2. This therefore avoids a warning on DEBUG=1 builds.
Inspired by patch in #8252 by Urias McCullough.
The HIDReportItem reads 32 bit chunks from the report buffer. To avoid
having to check the remaining buffer space on each extraction, we pad
the buffer so it is always valid to read 32 bits at a time. Also add
a comment explaining why we do it that way.
Thanks to Johannes Anderwald for pointing out the potential out of
bound access!
Calling SetIcon(NULL) calls MakeEmpty() that tries to delete all
manipulators on fState. So we may only delete fState after that call.
Also reported as CID 10856.
When forking a team, copy on write areas (and therefore caches) are
created for all the areas in the parent team, but they were always
created as swappable. If the parent team had some B_FULL_LOCK areas,
which aren't swappable, the wrong type of cache would be created which
lead to them not being mergeable later on (causing a panic).
Comments about a possibly cleaner way to figure out the cache type
would be welcome.
* Define a MEMALIGN macro that is either just defined to malloc() or
to the actual memalign() depending on where KMessage is used. We only
use memalign() inside the kernel and libroot.
* Add a comment to the macro explaining that this allows the use of
special heap implementations that might return unaligned buffers for
debugging purposes.
The change in hrev43405 wasn't correct, as it put the reference
object definition after the one of the corresponding locker, causing
the reference to be released before the unlock would happen.
Finally fixes#8187. Thanks Ingo for pointing that out.
* The call to _TeamDied() causes the team that the iterator points to
be removed from the map. Therefore the iterator becomes invalid and
may not be accessed anymore (including incrementing it). As we've had
to unlock, anything might have happened to to map, so take the safe
route and just start over.
* For each dead team that was found the AppManager was unlocked, but
there were no balancing lock calls, therefore causing the lock count
to get corrupted.
While this isn't really correct, it works for the use case it is
intended and doesn't open the can of worms we get when trying to do
memalign() across platforms (due to build tools use of KMessage).
* If we cloned the buffer due to misalignment, only free the old buffer
if we actually own it (i.e. if it was allocated by us).
* Set the KMESSAGE_OWNS_BUFFER flag after cloning the buffer. Previously
the buffer was leaked in the clone case.
* If there is an alignment requirement then better use memalign() to
make sure that it is met.
* Since the BMessageAdapter possibly sets a buffer directly, make a
properly aligned copy of the buffer if it happens to be misaligned.
* Not including malloc.h caused the memalign() signature to not be a C
signature, therefore leading to linking errors. Fix the missing
include and explicitly add extern "C" as well.
* Some remaining asterisk style cleanup.
The fModes array is realloc'ed as needed when adding modes. Therefore
the fModes pointer handed in to AddModes() becomes invalid once
_MakeSpace() returns in that function causing a freed memory block to
be used as input.
To avoid that we make a copy of the base mode list and then use that to
add the modes for each color space.
The file content isn't normally 0 terminated, so making a string out of
it would usually result in reading beyond the allocated buffer to find
the string length, possibly leading to a crash.
The operator const char*() automatically converts to the needed type
so the explicit BString::String() call isn't needed here. Thanks to
Clemens for pointing that out.
The guarded heap uses mprotect() to protect freed/unallocated pages so
that any access to such a page results in a segfault. It also installs
a segfault handler that in such an event prints some info about the
accessed page and then calls the debugger with a meaningful message.
It implements the same interface as the debug heap so it can simply be
swapped out by changing the Jamfile. As it doesn't support most of the
extra debug features (wall checking is obviously superfluous, but it
also doesn't help in leak checking) and as it is hugely space
inefficient I left it disabled for now.
The BString is destroyed when the function returns and takes the
storage pointed to by BString::String() with it, so returning such a
pointer is bogus. Instead the return type is now a BString which takes
over ownership of the string.
* We may get non-terminated strings so we need to use the
UTF8NextCharLen() version that works with a length. Previously we may
have read beyond buffers, possibly leading to crashes.
* Also the length parameter is used as an actual length and not as
buffer size. The length check was wrong before, which resulted in the
function returning too early if an offset was supplied.
* Added a comment about the guaranteed 0 termination in one case.
* Minor cleanup.
This one works with non-terminated strings that we may need to handle.
It also validates that the sequence is valid UTF-8 so it results in
the same behaviour as the version that is used when converting to
codes (syncing the enumeration and drawing behaviour).
The string that is built for hashing the escapements for missing
chars was not 0 terminated, leading to accesses past the string.
Depending on what followed an allocation that could lead to too long
strings being sent to the app_server for evaluation (where, due to
defensive, programming nothing bad would actually happen). In the
unfortunate case that nothing followed the allocation (i.e. end of
heap area), it could also lead to an application crash.
Therefore ensure 0 termination of the string, check for allocation
failure and use memcpy() instead of a for loop to copy the bytes from
one string to the other.
When setting memory protection, only ensure/wait for the range that
needs to be protected to not be wired instead of requiering the whole
area to be non-wired. The memory protection is done page wise and
having some parts of the area wired shouldn't preclude other parts to
be protected.
* Avoid needless adding of the death entry if the sem is gone already.
* Delete objects as soon as they aren't needed anymore and return
early where possible.
* Contain the thread == NULL case in its block and return from there as
well instead of non-obviously figuring out what happened later.
* Pull out the return code asignment.
* Minor cleanup.
While it was detected that the thread is in the destruction phase
and that it was necessary to wait and then have a valid status code
in the death entry, that status code wasn't actually returned. This
lead to uninitialized values for the return code even though
wait_for_thread[_etc]() would return B_OK.
For full- and lowspeed devices the unused ping status bit works as an
additional error bit (albeit it's so generic that it isn't really
useful). Include that bit when the error counter counts down to zero.
Also ensure that an error is returned if the error counter reaches
zero, but print a warning if none of the describing bits are set.
Removing the team from the group may have released the last reference
to the group and freed it. Since we still have a locker on that group
it would later crash on unlock, therefore we need a reference to the
old group before removing the team from it.
Depending on the use case the grow size may be too large to fit into
address space holes. Instead of failing try with smaller sizes until
it either worked or doesn't make sense anymore (< 1MB).
Pages that are freed are added to the tail of the list while allocation
candidates are taken from the head. Therefore pages that have been free
the longest are preferred, making immediate re-use less likely.
Also avoid looking for pages if the free count already tells that the
allocation can't be fulfilled.
This allows to use the debug features of the guarded heap also on
allocations made through the object cache API. This is obivously
horrible for performance and uses up huge amounts of memory, so the
initial and grow sizes are adjusted accordingly.
Note that this is a rather simple hack, using the object_cache pointer
to transport the allocation size. The alignment is neglected completely.
The buffer may have been freed if its data was added to the queue, but
later the buffer size was still read from the object. A spurious
acknowledge may have been sent, or one would have gone missing,
depending on what happened with the allocation after it was freed.
The call to _MakeSpace() may move the extent data from the indirect
array (kept in a heap allocation) to the direct one kept inside the
class. In that case the lastExtent pointer would become stale and
further use of it would've lead to suboptimal extents in the best case
to reading/writing at the wrong point in files and possibly corruption
of another allocation in the worst (both unlikely though).
To mitigate that we now re-initialize the pointer to the correct location
if we hit the cache limit.
Also made the use of the start variable more understandable. Instaed of
decrementing it (possibly wrapping) when an extent wasn't going to be
used and later adding the vector index again, just increment whenever
we actually move to the next extent.
For bad things to happen a few conditions needed to come together though:
1. There needed to be multiple vectors that could be combined with the
existing last extent.
2. There first needed to be more extents than the cache limit and that
number then had to decrease below the cache limit again.
3. The memory needed to stay intact after being freed up until after the
evaluation (or similar enough data had to be written to it).
At least the last one was guaranteed to not be true anymore since we
re-introduced overwritting freed memory with 0xdeadbeef in the slab,
therefore nastily hiding this. I'm not sure that the first condition is
ever met either (probably the vectors are combined beforehand so that
there never are multiple adjacent ones) at least for the normal use case
(the page writer writing back pages). I was at least unable to reproduce
an actual file corruption in my testing.
Just the out of bounds access to the stale pointer happened rather easily
though and is now at least fixed.
Further in the process the flat argument size is rounded up, but the
actual allocation was done with the unaligned size causing an access
beyond the allocation when later copying the flat arguments. It didn't
do any actual harm as the block sizes of our allocator(s) use elements
that have at least such an alignment.
The device is added to the root devices list when initializing, but was
not removed from there again when the root device was removed and freed,
causing the list to have a stale entry. Probably fixes#3305.
The list is populated once for the _fbsd_init_hardware iteration and, if
a device was found, again for _fbsd_init_drivers. The only thing I don't
understand is why it didn't just always crash, as there should have been
a stale list entry in any case when a supported device actually was found...
This is a very simple heap implementation that allocates memory so that
the end of each allocation always coincides with a page end and is
followed by a guard page which is marked non-present. Out of bounds
access (both read and write) therefore cause a crash (unhandled page
fault).
Note that this allocator is neither speed nor space efficient, indeed it
wastes huge amounts of pages and address space so it is quite easy to
hit limits. It is intended as a pure debug feature.
This adds a pair of functions vm_prepare_kernel_area_debug_protection()
and vm_set_kernel_area_debug_protection() to set a kernel area up for
page wise protection and to actually protect individual pages
respectively.
It was already possible to read and write protect full areas via area
protection flags and not mapping any actual pages. For areas that
actually have mapped pages this doesn't work however as no fault, at
which the permissions could be checked, is generated on access.
These new functions use the debug helpers of the translation map to mark
individual pages as non-present without unmapping them. This allows them
to be "protected", i.e. causing a fault on read and write access. As they
aren't actually unmapped they can later be marked present again.
Note that these are debug helpers and have quite a few restrictions as
described in the comment above the function and is only useful for some
very specific and constrained use cases.
They can be used to mark pages as present/non-present without actually
unmapping them. Marking pages as non-present causes every access to
fault. We can use that for debugging as it allows us to "read protect"
individual kernel pages.
The change to this initial index for safemode was brought in with the
flat import of the package manager branch in 323b654 where presumably
more paths were used. With this value selecting either just safe mode
or disable user add-ons would lead to no input_server add-ons being
loaded at all, leading to a system without input.
Package management will move the directory from common/etc to
common/settings/etc. The kernel side change that sets up the etc symlink
in the rootfs was already commited, everything still installs into the
old dir however. This symlink makes things that depend on /etc work for
now and can be removed once the files aren't populated to the old place
anymore.
Getting the object slab does a hash lookup which needs to be protected
by the cache lock. Otherwise the hash table may be resized or otherwise
modified while we do the lookup, leading to errors.
* The vm86 code or the code running in virtual 8086 mode may clobber the
%fs register that we use for the CPU dependent thread local storage
(TLS). Previously the vm86 code would simply restore %fs on exit, but
this doesn't always work. If the thread got unscheduled while running
in virtual 8086 mode and was then rescheduled on a different CPU, the
vm86 exit code would restore the %fs register with the TLS value of
the old CPU, causing anything using TLS in userland to crash later on.
Instead we skip the %fs register restore on exit (as do the other
interrupt return functions) and explicitly update the potentially
clobbered %fs by calling x86_set_tls_context(). This will repopulate
the %fs register with the TLS value for the right CPU. Fixes#8068.
* Made the static set_tls_context() into x86_set_tls_context() and made
it available to others to faciliate the above.
* Sync the vm86 specific interrupt code with the changes from hrev23370,
using the iframe pop macro to properly return. Previously what was
pushed in int_bottom wasn't poped on return.
* Account for the time update macro resetting the in_kernel flag and
reset it to 1, as we aren't actually returning to userland. This
didn't cause any harm though as only the time tracking is using that
flag so far.
* Some minor cleanup.
The constructor may abort at various places and the destructor cleans up
everything already initialized. The mutex was however not initialized
early on, leading to #8153 where the mutex was destroied in the error
case, accessing uninitialized memory. Fixes#8153 though the reason for
the aborted constructor probably needs to be investigated as well.
Validate the candidate child device a bit more by checking the device ID
and the base and subclass of the device. We don't even know if the child
is still on the PCI bus and some firmware may mark disabled devices by
simply invalidating one of these values. Possibly fixes#8111.
Added TODO concerning that we might not want to fail at all since we
ensure that we matched all devices after routing preparation at which
state we would notice any missing child devices anyway.
While the log of hrev35726 says that unusable page ranges are supposed
to be marked with PAGE_STATE_UNUSED and allocated ones with
PAGE_STATE_WIRED, both actually marked with PAGE_STATE_UNUSED.
When limiting the available memory by reducing the page count it may not
be enough to just limit sNumPages. Depending on the physical memory map
non existing pages between ranges (sNonExistingPages) would still be
added up and later subtracted from the sNumPages, resulting in a wrong
max page count. Also due to the fixed removal of non existing page
ranges the actually available memory would usually not be the amount
set via LIMIT_AVAILABLE_MEMORY.
Instead we now calculate the available memory when going through the
physical memory ranges and limit/exit as soon as we've reached the
desired amount of available memory (also ignoring further non-existing
pages).
* Ensure that we don't underflow the used_pages count and that used
+ cached pages don't overflow max_pages. As there is no locking the
values may change while we read them so that such situations could
arise.
* Make the TODO about the missing locking into a Note explaining the
above, as it is not really worth adding locking here. The stats are
only informational.
* The altered used pages calculation of hrev43168 wasn't correct, as
the inactive page queue may (validly) contain mapped pages as well.
Those would then get counted twice (as they are included in
gMappedPagesCount already).
Instead we calculate the used pages from the total page count, minus
everything we account for otherwise. Doing it this way is possible
without introducing any additional counters, as all the counts to
subtract are already present (as opposed to some of the ones that
would be needed for adding the counts up). Fixes#8109.
* Added TODO regarding the problem of not locking any of the counters
which runs the risk of them getting modified while we haven't yet read
all of them.
use of an attribute may cause an attribute directory access, causing a get_vnode
call that leads to KDL due to the mount not yet having completed as seen in
#8090. Moving the volume_ops initialization in bfs_mount earlier might make this
work, but it is a hack at most, as we can't really know what state the VFS is in
during a mount.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43229 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also reset the local and IO APIC base physical addresses when configuration
failed.
Should fix#8102, but is otherwise untested for lack of old enough hardware.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43217 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the slab code. It is generic as it only contains the link to a tracing entry
and not any application specific info.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43188 a95241bf-73f2-0310-859d-f6bbb57e9c96
available when there is none instead of spinning around. Might help with #8053
and #8058, though it's possible that leaks or interrupt issues are the cause
for these.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43125 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Add "allocation_infos" KDL command. Can be used to print the allocation info,
including the stack trace, given an object cache, slab, allocation within a
slab or allocation address. It can also optionally be filtered by team/thread.
* Fix the AllocationDetailPrinterCallback to not access a possibly invalid
trace entry for printing a stack trace.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43118 a95241bf-73f2-0310-859d-f6bbb57e9c96
Add MemoryManager::DebugObjectCacheForAddress() to retrieve the ObjectCache for
a certain address from KDL.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43117 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Introduce TracingMetaData::IsInBuffer() to validate that a certain memory
range is within the valid tracing buffer limits.
* Use that when validating in tracing_is_entry_valid() before trying to access
the entry, resolving a TODO.
* Validate the candidate time against the handed in time (if specified) as an
additional check.
* Tiny unrelated text cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43116 a95241bf-73f2-0310-859d-f6bbb57e9c96
return a stack trace when tracing is disabled we don't really need to be able
to print one either.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43088 a95241bf-73f2-0310-859d-f6bbb57e9c96
Michael Lotz