Request for feature

[Richard Achmatowicz]

Hello JCarder

I'm trying to use JCarder with my ant-driven JUnit test suite and
experiencing some difficulties due to JCarder always writing its lock
statistics to files named jcarder_events.db and jcarder_contexts.db.

My JUnit testsuite is organized in such a way that it runs tests in
batches, and within each batch, each test is set up to run in its own
jvm. The JVM startups are overwriting the events and contexts files
generated from the previous startup.

What would really help me a lot is two things:
(i) the ability to specify my own names for the files
jcarder_events.db and jcarder_contexts.db, as well as the output
directory. This would allow me to keep track of multiple lock
generating sessions, corresponding to my multiple test runs ;
(ii) the ability to open jcarder_events.db and jcarder_contexts.db for
appending (instead of creating a new file each time). This is more or
less required (it seems) if I want to run a suite of JUnit tests each
using its own JVM to run the test in (forkmode="perTest" in the junit
ant task). Running all tests in a single JVM runs into problems with
timeout's causing the whole JVM to be terminated.

At the moment, i'm being stymied by tests timing out (due to the
slower execution time) and killing off the remainder of the test run
when running with forkmode="once".

Otherwise, a *very* useful debugging tool.

Richard

[Ulrik Svensson]

Thank you Richard!

I have not yet had time to try JCarder for analyzing test cases
executed with JUnit & Ant, so I'm curious about your findings!

Would it, in your use case, be possible to specify different unique
output directories for each session, with the existing java system
property "jcarder.outputdir" and the command line argument "-d",
instead of adding a new configuration setting for each file?

Adding a new system property for opening jcarder_events.db and
jcarder_contexts.db in append mode would be a small change, but you
would still not find any more cycles than if you were analyzing the
sessions one by one, since no lock instances are shared between the
JVM instances. Is there still a point in adding an append mode?

I understand that the execution time for the test cases is increased
while executed with JCarder, and that you might have to adjust your
timeouts. But I don't see why executing test cases in separate JVMs
would affect the timeouts?

Do you know if your test cases, JUnit or Ant are using some special
class loading mechanism?

/Ulrik

On Feb 6, 2008 1:37 AM, Richard Achmatowicz

[Richard Achmatowicz]

Hi Ulrik

Thank you for your reply. The issues I cited were just problems I had
in making use of JCarder in the context of an ant-based JUnit
testsuite. I managed to work around them temporarily, so they are less
of an issue at present.

What is an issue were the results I got running JCarder against our
testsuite for JGroups (http://www.jgroups.org/javagroupsnew/docs/
index.html). I ran JCarder several times against runs of our
testsuite, and always got similar results - lots of locks being taken,
but no potential deadlocks. The results are at the end of this mail.

JGroups is a highly concurrent application, and we're a little worried
that so many locks can be taken without one possible deadlock being
found. Any ideas on how we could investigate this anomaly further?

Regards

Richard

[nrla@localhost udp]$ java -jar ../../lib/jcarder.jar
Opening for reading: /tmp/jgroupsb26/tmp/udp/jcarder_contexts.db
Opening for reading: /tmp/jgroupsb26/tmp/udp/jcarder_events.db
Loaded from database files:
Nodes: 9970
Edges: 17693 (excluding 11487 duplicated)
Cycle analysis result:
Cycles: 0
Edges in cycles: 0
Nodes in cycles: 0
Max cycle depth: 0
Max graph depth: 3
No cycles found!

[nrla@localhost tcp]$ java -jar ../../lib/jcarder.jar
Opening for reading: /tmp/jgroupsb26/tmp/tcp/jcarder_contexts.db
Opening for reading: /tmp/jgroupsb26/tmp/tcp/jcarder_events.db
Loaded from database files:
Nodes: 31745
Edges: 55180 (excluding 73044 duplicated)
Cycle analysis result:
Cycles: 0
Edges in cycles: 0
Nodes in cycles: 0
Max cycle depth: 0
Max graph depth: 4
No cycles found!

[nrla@localhost mux-udp]$ java -jar ../../lib/jcarder.jar
Opening for reading: /tmp/jgroupsb26/tmp/mux-udp/jcarder_contexts.db
Opening for reading: /tmp/jgroupsb26/tmp/mux-udp/jcarder_events.db
Loaded from database files:
Nodes: 22971
Edges: 39789 (excluding 55626 duplicated)
Cycle analysis result:
Cycles: 0
Edges in cycles: 0
Nodes in cycles: 0
Max cycle depth: 0
Max graph depth: 5
No cycles found!


[nrla@localhost mux-tcp]$ java -jar ../../lib/jcarder.jar
Opening for reading: /tmp/jgroupsb26/tmp/mux-tcp/jcarder_contexts.db
Opening for reading: /tmp/jgroupsb26/tmp/mux-tcp/jcarder_events.db
Loaded from database files:
Nodes: 35875
Edges: 65206 (excluding 77017 duplicated)
Cycle analysis result:
Cycles: 0
Edges in cycles: 0
Nodes in cycles: 0
Max cycle depth: 0
Max graph depth: 5
No cycles found!

On Feb 6, 5:48 pm, "Ulrik Svensson" <ulri...@gmail.com> wrote:
> Thank you Richard!
>
> I have not yet had time to try JCarder for analyzing test cases
> executed with JUnit & Ant, so I'm curious about your findings!
>
> Would it, in your use case, be possible to specify different unique
> output directories for each session, with the existing java system
> property "jcarder.outputdir" and the command line argument "-d",
> instead of adding a new configuration setting for each file?
>
> Adding a new system property for opening jcarder_events.db and
> jcarder_contexts.db in append mode would be a small change, but you
> would still not find any more cycles than if you were analyzing the
> sessions one by one, since no lock instances are shared between the
> JVM instances. Is there still a point in adding an append mode?
>
> I understand that the execution time for the test cases is increased
> while executed with JCarder, and that you might have to adjust your
> timeouts. But I don't see why executing test cases in separate JVMs
> would affect the timeouts?
>
> Do you know if your test cases, JUnit or Ant are using some special
> class loading mechanism?
>
> /Ulrik
>
> On Feb 6, 2008 1:37 AM, Richard Achmatowicz
>