[haiku-commits] Re: haiku: hrev48990 - headers/os/support headers/posix src/system/libroot/posix/malloc_debug
- From: Michael Lotz <mmlr@xxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sat, 11 Apr 2015 19:05:32 +0200
On 11.04.2015 16:33, Paweł Dziepak wrote:
2015-04-05 16:06 GMT+02:00 Michael Lotz <mmlr@xxxxxxxx
The option with the default alignment therefore allows the use with
software that requires such an alignment while not making the
feature less useful for cases where it isn't needed.
That looks more like an inherent limitation of the guarded heap
implementation rather than something that can be fixed by violating
alignment requirements. Writing some data to the unprotected bytes after
the end of the buffer and then verifying that they weren't changes may
be some way of trying to alleviate that issue (obviously the
disadvantage is that we won't get abort exactly at the moment incorrect
write is performed, and it won't work for reads). Anyway, currently the
best way to verify memory accesses seems to be using compiler
instrumentation as AddressSanitizer undoubtedly makes any paging-based
approaches obsolete.
Yes, the guarded heap has this inherent limitation and I am fully aware
of it. Another limitation is that it doesn't detect out of bounds access
in the other direction, the address space and page waste making it
unusable for applications with large amounts of small allocations, etc...
For the record I implemented the wall checking approach in the normal
debug heap some years ago. Frankly it's just not really helpful if it
doesn't trigger right on the spot. You can detect "something is wrong"
with it (which you usually can see by it crashing or behaving
incorrectly anyway), but it doesn't really tell you where it goes wrong.
And it doesn't work for reads, as you say, making all the use-after-free
cases I fixed recently invisible.
I know of AddressSanitizer and it would be the ideal tool to use here.
It indeed makes the whole approach obsolete, which is a good thing.
Unfortunately it isn't yet available under Haiku. Given that I've
written the guarded heap and know where and how to extend it to suit my
needs, doing so has a rather low barrier of entry for me. That's why I
figured I'd build on top of what was already there to get some immediate
results.
The fact that it is only a debug tool doesn't mean that the code quality
isn't important anymore. ;)
I take issue with this allegation. This is not a question of code
quality, we're talking about a default value and not about me hacking in
some gross pile of code without thinking.
You brought up valid points during this discussion, the one of
std::max_align_t was pretty much immediately addressed, the one of
unaligned access breaking atomics is a new one and shall be addressed in
a future commit.
I realize that the use of such crude and inherently broken approaches is
not pretty. When you know about the limitations you can still get pretty
nice results out of them. In my opinion this makes it worth using them
and investing some reasonable effort in making them better while waiting
for a better solution. If we decide that this dabbling should better
happen in my own private branch and not clobber the Haiku repository
directly, I can certainly move it to github instead.
Regards,
Michael
Other related posts:
