search

staticanalysis / data-race-test

Automatically exported from code.google.com/p/data-race-test
0 stars 0 forks source link

Java: jtsan fails to detect THR_START event on a simple test #31

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
% cat RaceExample.java
public class RaceExample {
  public static int racey_var;

  static class RaceThread extends Thread {
    public void run() {
      RaceExample.racey_var++;
    }
  }

  public static void main(String args[]) {
    (new RaceThread()).start();
    (new RaceThread()).start();
    System.out.printf("racey_var=%d\n", racey_var);
  }
}
% javac RaceExample.java
% java RaceExample
racey_var=1
% ./jtsan.sh RaceExample
Java Agent: appending threading events to file: jtsan.events
racey_var=0
% grep THR_ jtsan.events
THR_START 0 0 0 0
THR_FIRST_INSN 0 0 0 0
%

Original issue reported on code.google.com by konstant...@gmail.com on 1 Mar 2010 at 3:46

GoogleCodeExporter commented 9 years ago 
at jtsan-r36 I made a change to intercept THR_START:
shell> ./jtsan.sh RaceExample
Java Agent: appending threading events to file: jtsan.events
racey_var=1
shell> grep THR_ jtsan.events
THR_START 0 0 0 0
THR_FIRST_INSN 0 0 0 0
THR_START 6 7 0 0
THR_START 7 7 0 0

this is done by intercepting all enters of all methods with name "run" and 
checking
for the Thread type in the EventListener

the PC shows line=0, however :( How critical is this?

BUT (!!!)

this will result in duplicate THR_START in ThreadSanitizerTest due to
EventListener.jlThreadStart() that is invoked *before* the new run() 
interception.
jlThreadStart must be eliminated. It might make more threads to start 
invisibly, but
I would rather not worry about this now, we don't see a lot of threads starting
because we don't instrument them yet.

I just realized, we need "THR_CREATE TID PC CHILD_TID 0" to create a 
happens-before
arc, this can be done by intercepting Thread.start. This is a new kind of
interception: "any method called start(), intercept before calling start(), not 
in
the method, as we can do now". Currently this kind of interception is not 
supported,
though should be easy to implement. How critical is this? Sounds like 
really-really
critical to me.

Original comment by egor.pasko@gmail.com on 8 Mar 2010 at 10:22

GoogleCodeExporter commented 9 years ago 
at r37 I removed the THR_START duplication, the new type of instrumentation is 
TBD

Original comment by egor.pasko@gmail.com on 8 Mar 2010 at 10:36

GoogleCodeExporter commented 9 years ago 
at mighty revision 39 I seem to have fixed the issue.

Original comment by egor.pasko@gmail.com on 14 Mar 2010 at 6:53