LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 2009
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2009.05.05 18:32 "Re: Packbits worst case encoded length", by Bob Friesenhahn
On Tue, 5 May 2009, Albert Cahalan wrote: >> wrong that the malloc library can not detect. Guard pages are only somewhat >> useful since they only cover the case where there is a linear overwrite past >> the end of the allocated buffer. > > Sure, but this is a **very** common and dangerous case. Is it more dangerous than the other cases? What would cause one case to be more dangerous than another? > Guard pages are pages of memory that you can't read or write. > There is no "original guard content" to preserve. Any attempt > to read or write to a guard page will cause an immediate crash. Ahhh, I see. This wastes a whole MMU page (4K, 8K, 16K, or ???) per memory allocation. It also needs to start on a MMU page boundary, which may be far beyond the user-requested allocation. If the user requests 128 bytes, then that leaves a long region which is unchecked and the underlying allocation really needs to be at least a page long. In order to be safe, there needs to be protection against underflow, so the page below needs to be a guard page as well. The end result is that there is huge waste of memory if the user allocations are small. It seems that the strategy taken can be controlled by which malloc library is linked to at library link time, program link time, or preloaded via an OS specific means. > Sure, though decompression code isn't dealing with those. > Decompression code is a common source of trouble. No doubt. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/