Using Chord on Open Programs?

[Reed Milewicz]

Hello! My name is Reed, and I'm a PhD candidate in the Department of Computer and Information Sciences at the University of Alabama at Birmingham. I'm interested in incorporating Chord into my dissertation research, and I had a question.

What I have is a mutation analysis framework that takes healthy concurrent code and introduces horrific bugs into that code. I then use an ensemble of static analysis tools to attempt to detect the bugs in the mutated code, and gather data about what they find (and don't find).

I really like the Chord tool and I'd like to include that in the ensemble. I downloaded it and did some testing, and everything looks very promising. However, what I'm not sure about is how to handle open programs like libraries with Chord. That is, there is no class with a main method to which I can point.

I've read Naik's 2008 thesis (top notch work, by the way), and in it, it was mentioned that there was support for open programs in the original tool. Is that still the case for the tool as it exists today? If I have to, I can generate a test harness on the fly for the mutated library code, but I was hoping that I could avoid that.

Thanks,

Reed Milewicz

[Ariel Rabkin]

It's possible to use Chord for open programs; I did it for Hadoop and
suchlike for *my* dissertation.
(http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-67.pdf)

As I recall, there were basically two strategies I used. First,
writing test harnesses. This is usually straightforward and can even
be automated -- you use Java reflection to slurp in the
class-under-test, and then emit a method call to each method, with
dummy int and string arguments to taste. A benefit of this is that you
can then manually refine the test harness to look more like real code.

Second, hacking the underlying analysis to add explicit points-to and
reachability rules to cover open programs. You do things like
creating a datalog relation of entry points; then specify that all
those are reachable, and that they can be called with the generic
object of each type as argument. I think my dissertation code is still
in the repository, and that took this approach.

--Ari

> --
> You received this message because you are subscribed to the Google Groups
> "chord-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chord-discus...@googlegroups.com.
> To post to this group, send email to chord-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/chord-discuss.
> For more options, visit https://groups.google.com/d/optout.



--
Ari Rabkin

[Reed Milewicz]

Ah, I see! I recognize your dissertation. I was leafing through it not too long ago.

I'm using the ROSE source-to-source compiler framework to do my mutations, and it'd be pretty easy to generate the harness automatically by scanning for visible methods and then conjuring calls with dummy values. But your second suggestion also sounds workable. I'll have to look into what you did in greater detail. 

Do you have a link to your repo? That is, if it's publically available. I was just interested in looking at it.

I'm doing this so I can collect enough training data to teach my deep learning system to perform a kind of stochastic static analysis. It tells me how much money it'd be willing to bet on this or that piece of code failing, and I use that data to prioritize more in-depth analyses and testing (e.g. model checking). 

Thanks! You've been most helpful.

[Ariel Rabkin]

Sure! My code is all still in the JChord source tree:
https://bitbucket.org/pag-lab/jchord/src/ec123fc7b19e5dbb66cfce6495edad8a7a251459/conf_analyzer/src/?at=master

As I recall, the core bit of logic for handing open code is here:
https://bitbucket.org/pag-lab/jchord/src/ec123fc7b19e5dbb66cfce6495edad8a7a251459/conf_analyzer/src/dlog/cipa_0cfa_arr.dlog?at=master&fileviewer=file-view-default#cipa_0cfa_arr.dlog-227:252


I would I think recommend the first approach if you can make it work
-- having a forked analysis is a bit of a pain for all the usual
reasons it's better not to fork a codebase.

[Reed Milewicz]

Fantastic! And yeah, I agree. But still, it's good to be informed about all the options.

Thanks again!

- Reed