Re: [abc] abc static analysis bug (fwd)

I've fixed this in Paddle revision 2277.

Here's the log message:

Fix cflow analysis bug reported by Sebastian Kanthak.
Call graph edges corresponding to thread starts (Kind.THREAD) need to
be handled specially in two ways. First, for mayCflow computation, they
must be excluded from the call graph. Second, for mustCflow computation,
all their targets must be treated as entry points. We were doing the
first but forgot to do the second. This change fixes this.

Ondrej

On Mon, Jan 30, 2006 at 11:31:00AM -0500, Laurie Hendren wrote:
> Ondrej,
>
> Can you take a look at this?
>
> Thanks, Laurie
>
>
> +-----------------------------------------------------------------
> | Laurie Hendren --- laurie.hendren@mcgill.ca
> | Associate Dean (Academic), Faculty of Science,
> | Dawson Hall, McGill University, 853 Sherbrooke St W,
> | Montreal QC H3A 2T6 Canada, 514-398-7179, fax 514-398-1774
> +----------------------------------------------------------------
> | For contact and home page info as Professor, Computer Science:
> | http://www.sable.mcgill.ca/~hendren --- hendren@cs.mcgill.ca
> | Research: http://www.sable.mcgill.ca http://aspectbench.org
> +----------------------------------------------------------------
>
> ---------- Forwarded message ----------
> Date: Mon, 30 Jan 2006 16:47:53 +0100
> From: Sebastian Kanthak <skanthak@gmail.com>
> Reply-To: sebastian.kanthak@muehlheim.de
> To: hendren@sable.mcgill.ca
> Cc: Mira Mezini <mezini@informatik.tu-darmstadt.de>,
> Michael Haupt <haupt@informatik.tu-darmstadt.de>
> Subject: abc static analysis bug
>
> Dear Mrs. Hendren,
>
> we recently submitted a paper on cflow implementations to PLDI, which
> was rejected. We have, however, received a very helpful review
> detailing the cflow optimisations as applied by abc.
>
> We are currently trying to incorporate some of the suggestions and are
> performing a more detailed analysis of our benchmarks. It seems I have
> hit a bug in abc's interprocedural cflow optimizations with our
> benchmark (attached to this e-mail).
>
> When compiling the benchmark with "-O3 -main-class TestAbc",
> unconditional advice execution is woven into Foo.foo() (although it
> can be reached outside the control flow) and Foo.m() does not contain
> any logic for updating the state of the control flow (although it must
> not be omitted, here). You can verify that something is wrong by
> running the benchmark twice; the first time compiled with -O1, the
> second time compiled with -O3. To run the benchmark, please use the
> following parameters and notice the "count=<n>" parameter in the
> output.
>
> java TestAbc 1 10 5 10 1
>
> When compiled with -O1, you'll get the correct value of "count=40",
> but with -O3 a value of "count=120" will be printed.
>
> I think the bug is caused by the way we spawn several threads in
> CFlow.run. Apparently, your call graph analysis does not correctly
> analyze which method gets executed due to Thread.start() (which is a
> very hard problem, in general), but I'm sure you can debug this issue
> better than I could.
>
> I hope this information is helpful to you.
>
> Sebastian Kanthak
>
> --
> Research Assistant
> Software Technology Group
> Darmstadt University of Technology, Germany
Received on Tue Jan 31 22:28:59 2006