Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Our malloc implementation is a lot more resistant (than Linux) to
"heap overflows in the malloc arena", but we wanted to improve things
even more.
Starting a few months ago, the following changes were made:
- We made the mmap(2) system call return random memory addresses. As well
the kernel ensures that two objects are not mapped next to each other;
in effect, this creates unallocated memory which we call a "guard page".
- We have changed malloc(3) to use mmap(2) instead of extending the data
segment via brk()
- We also changed free(3) to return memory to the kernel, un-allocating
them out of the process.
- As before, objects smaller than a page are allocated within shared
pages that malloc(3) maintains. But their allocation is now somewhat
randomized as well.
- A number of other similar changes which are too dangerous for normal
software or cause too much of a slowdown are available as malloc options
as described in the manual page. These are very powerful for debugging
buggy applications.
Other results:
- When you free an object that is >= 1 page in size, it is actually
returned to the system. Attempting to read or write to it after
you free is no longer acceptable. That memory is unmapped. You get
a SIGSEGV.
- For a decade and a bit, we have been fixing software for buffer overflows.
Now we are finding a lot of software that reads before the start of the
buffer, or reads too far off the end of the buffer. You get a SIGSEGV.
