The previous solution had various issues where argv pointed to stack-based
objects that had potentially been destroyed/overwritten already. Fixes
#8173.
- Modify _SetupGDBArguments() to return an error code and check for it
accordingly.
The previous solution had various issues where argv pointed to stack-based
objects that had potentially been destroyed/overwritten already. Fixes
#8173.
- Modify _SetupGDBArguments() to return an error code and check for it
accordingly.
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.
* This tool was created and implemented in draft during GCI 2011
by Aleksas Pantechovskis, <alexp.frl@gmail.com>;
* Later it was heavily refactored and optimized to Haiku Coding
Standards by Siarzhuk Zharski;
* Icons support still missing;
* Thank you for the contribution, Aleksas!
Signed-off-by: Siarzhuk Zharski <zharik@gmx.li>
* 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.
* GLTeapot 3D model data moved from the text file "teapot.data" into
Application resources;
* Fixes#4934 and completes GCI 2011 task made by Aleksas Pantechovskis.
Thanks for contribution!!!
Signed-off-by: Siarzhuk Zharski <zharik@gmx.li>
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.
As a last fall-back, try to launch the test_registrar from the same
directory as run_test_registrar. This makes launching the app_server
test environment from a volume without Query support work.
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.
