Closed GoogleCodeExporter closed 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
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
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
Original issue reported on code.google.com by
konstant...@gmail.com
on 1 Mar 2010 at 3:46