6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated

[Rémi Forax]

Hi Alan,
in MappedBytBuffer:
pagePosition() should return a long, this will avoid most of the casts.
mappedPageCount() should take the value of mappedLength() as parameter
and mappedAddress() and mappedLength() should take the value of
pagePosition() as parameter to avoid to calculate pagePosition() more 
than once.

In load, you store the pageSize() in ps but doesn't use it after,
I suppose that your intention was to use it in the loop.

for (int i=0; i<count; i++) {
   unsafe.getByte(a);
   a += ps;
}

otherwise, it looks fine.

Rémi

Le 26/07/2010 14:29, Chris Hegarty a écrit :
> Alan - The changes looks great.
>
> -Chris.
>
> On 07/21/10 15:36, Alan Bateman wrote:
>>
>> If the file underlying a mapped byte buffer is truncated then it's
>> possible that invoking the MappedByteBuffer's load method will SIGBUS.
>> The reason is that the load touches each page in a native method and the
>> VM's handler cannot deal with the fault. A second and related issue
>> (6799037) is that same native code is reading an int from each page
>> without taking alignment into consideration or the possibility that it
>> might read beyond the end of the mapping. Yet another issue, is that
>> isLoaded fails with an IOException for the case that the mapping doesn't
>> start on a multiple of the page size. The load method has a similar
>> problem but it doesn't throw IOException because it is ignoring the
>> return value from madvise(3C).
>>
>> The webrev with the proposed changes to fix these issues is here:
>> http://cr.openjdk.java.net/~alanb/6934977/webrev
>>
>> The main change is that load is changed to touch the pages via Unsafe
>> and so uses the existing handler.
>>
>> -Alan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100726/ce32286e/attachment.html