Bug in interrupt handling in FileChannelImpl.map( … )

[Chris Dennis]

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



On 9/18/13 10:04 AM, "Chris Dennis" <chris.w.dennis at gmail.com> wrote:

>The Chris Dennis on the OCA list is me, I've just switched my openjdk mail
>subscriptions to my gmail address due to work email quotas. I'll prepare a
>patch against jdk8/tl, and look in to the possibility of creating a test
>that attempts to reproduce this (although as you say it may be
>impractical).
>
>Thanks,
>
>Chris
>
>On 9/18/13 9:59 AM, "Alan Bateman" <Alan.Bateman at oracle.com> wrote:
>
>>On 18/09/2013 14:53, Chris Dennis wrote:
>>> I'm interested in pushing this issue to a conclusion, and I'm happy to
>>> contribute a fix. What forest should I be generating a patch against?
>>>
>>The "How to contribute" is the starting point. I see there is a Chris
>>Dennis on the OCA list but I don't know if that is you.
>>
>>The forest that we push core area changes to is jdk8/tl. We try to
>>include a test with all changes although hear I suspect it may be too
>>troublesome to write a test that duplicates this without having side
>>effects.
>>
>>-Alan
>>
>>[1] http://openjdk.java.net/contribute/
>>
>>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8024833.patch
Type: application/octet-stream
Size: 7542 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130920/95e5e2ac/8024833.patch