Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8145981

(fs) LinuxWatchService can reports events against wrong directory

XMLWordPrintable

    • b100
    • x86
    • linux
    • Verified

        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 :-)

          1. Repro.java
            2 kB
            Pallavi Sonal
          2. wakeup.patch
            2 kB
            Alan Bateman

              sebastian Sebastian Sickelmann
              webbuggrp Webbug Group
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: