Bug in interrupt handling in FileChannelImpl.map( … )

[Chris Dennis]

Okay looks like I had an incorrect assertion in the test, (an artifact due
to the copy paste I performed from the InterruptDeadlock test).  I cannot
assert that the channel is closed after all the threads have completed
(they could all get through the map call before the interrupting thread
gets to them).  Attached is a corrected version of the patch.

Chris

On 10/16/13 8:52 AM, "Chris Dennis" <chris.w.dennis at gmail.com> wrote:

>I'll look in to the test when I get a chance.  I haven't seen it fail this
>way - but like I said the close logic is a bit weird in order to try and
>make the failure 'clean'.  I'll look through it and see if I can figure
>out what might be going wrong.
>
>Chris
>
>On 10/15/13 11:47 AM, "Alan Bateman" <Alan.Bateman at oracle.com> wrote:
>
>>On 23/09/2013 14:33, Chris Dennis wrote:
>>> 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.
>>>
>>Just coming back to this. The patch to FileChannelImpl.map looks fine
>>(and the update to when map needs to extend the file is okay too). I'm
>>happy to sponsor this and get it in.
>>
>>I'm not sure about the test yet, it appears to fails intermittently (on
>>several platforms), typically because the FileChannel isn't closed. Have
>>you seen this? I haven't dug into it yet but we would need the test to
>>be very reliable to include it with the patch.
>>
>>-Alan.
>>
>>
>
>

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