-
Bug
-
Resolution: Fixed
-
P3
-
8u60
-
b100
-
x86
-
linux
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8183701 | 8u161 | Sebastian Sickelmann | P3 | Resolved | Fixed | b01 |
JDK-8162378 | 8u152 | Sean Coffey | P3 | Resolved | Fixed | b01 |
JDK-8192437 | emb-8u161 | Sebastian Sickelmann | P3 | Resolved | Fixed | b01 |
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 :-)
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 :-)
- backported by
-
JDK-8162378 (fs) LinuxWatchService can reports events against wrong directory
-
- Resolved
-
-
JDK-8183701 (fs) LinuxWatchService can reports events against wrong directory
-
- Resolved
-
-
JDK-8192437 (fs) LinuxWatchService can reports events against wrong directory
-
- Resolved
-