Bug in interrupt handling in FileChannelImpl.map( … )

[Chris Dennis]

Sure, no problem. There are a couple of oddities to note in the test…

1. It doesn't actually end up mapping anything. I'm intentionally trying
to extend the file from zero length to length one, when the file is
read-only.  This way I pass through the nested size call, but don't
actually end up mapping anything.  Seemed to me like this was the simplest
way to test exactly this bug and nothing else, and also avoid all the
windows specific mapping behaviors causing any problems.
2. I'm not closing the file in a finally block because when the code is
broken the locking will block the close call, hence I'm only closing on a
successful run.

Thanks,

Chris

On 9/22/13 11:29 PM, "Alan Bateman" <Alan.Bateman at oracle.com> wrote:

>On 20/09/2013 07:14, Chris Dennis wrote:
>> Alan,
>>
>> Attached is my proposed fix for this issue.  I've sneakily snuck in a
>> second minor fix, it seems to me we should be checking for !isOpen()
>>after
>> the truncate call (figured we could stretch the title of the bug to
>>cover
>> this too…).  The test I've checked in was the best I could do at short
>> notice, it doesn’t fail very often, but if you ramp up the cycle count
>>or
>> run it repeatedly I can get it to fail eventually (can take thousands of
>> cycles).  It's not going to catch any regression immediately but with
>> enough aggregated runs it should eventually.
>>
>> Thanks,
>>
>> Chris
>>
>Thanks Chris. The update to FileChannel looks okay and I will sponsor
>the change.  I need to study the test, just to be satisfied on its
>reliability. It's okay that it won't detect the issue reliability, it's
>really just to check that we won't have any false positives or else
>issues on Windows where jtreg can't clean up after the test due to the
>mapped regions. I'll get back to you soon on this (JavaOne keeping many
>of us busy this week).
>
>-Alan.