JDK-8145981 : (fs) LinuxWatchService can reports events against wrong directory
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 8u60
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2015-09-16
  • Updated: 2017-11-29
  • Resolved: 2015-12-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u152Fixed 9 b100Fixed
Description
FULL PRODUCT VERSION :
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux 2.6.32-358.23.2.el6.x86_64 #1 SMP Sat Sep 14 05:32:37 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
In LinuxWatchService$Poller.run(), you read from the inotify file descriptor into an unmanaged buffer called "address". If there is data available on socketpair[0] you then read from that file descriptor *into the same buffer*.

This means that in the case where both the inotify FD and the socketpair[0] FD have data available, you end up corrupting at least 1 byte of the inotify event stream with data from socketpair[0] (which is basically just junk data).

In the most common case, this corruption just corrupts 1 byte of data, so the LSB of the first watch descriptor in the event stream will be changed. This causes the WatchService to report inotify events against the wrong Path -- e.g. if you have subscribed to directories A and B, and then touch file A/C, you'll actually see a WatchEvent for the path B/C.

As far as I can tell this bug has been present since at least 2011.


REPRODUCIBILITY :
This bug can be reproduced occasionally.

CUSTOMER SUBMITTED WORKAROUND :
Reimplement the WatchService using JNA :-)


Comments
I have attached an initial patch for this, it is an oversight in the original implementation. Basically the checking for wakeup events is moved to after the processing of events. An alternative would be a small buffer to read wakeup events but it's not really needed.
28-12-2015

I think the author posted this as the follow up: http://blog.omega-prime.co.uk/?p=161 Which makes me wonder if there is a communication breakdown somewhere?
08-12-2015