[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CFG and body dumping options (Was: About revision 1407)

John Jorgensen wrote:
"vranganath" == Venkatesh Prasad Ranganath <vranganath@cox.net> writes:


vranganath> Hi, I am using revision 1407.

    vranganath> ExceptionalUnitGraph has a DEBUG flag that causes
    vranganath> humongous exception dumps. It would be much
    vranganath> simpler and convenient for the users if Soot
    vranganath> embraced a logging framework.  Just a suggestion.

I actually don't know enough about logging frameworks to make an
informed response to your suggestion, but I feel an obligation to
say something about the motivation for these dumps, since I'm their
perpetrator.  And not only are they humongous, they also create
ugly filenames that include spaces and punctuation marks.

Since we will have to decide whether to leave this dump option in
place for the next release, I'm going to take advantage of your
question to bring the option's existence to the notice of other
Soot developers, though that will involve explaining some things
that you, Venkatesh, have already figured out for yourself.

The dumps occur if you specify some value for soot's new

--dump-cfg <phase>

option, which says to dump dot-file representations of all the
CFGs produced during the phase named <phase>.  Or you can say

--dump-cfg ALL

and get a dot file for every single CFG that soot produces.

--dump-cfg has a companion option which actually predates it:

--dump-body <phase>

that says dump a representation of the intermediate
representation of each method body before and after <phase>, or
before and after each phase, if you specify

--dump-body ALL

The origins of --dump-body go back to last spring, when we were
updating the documentation for Soot's command line options.
Since we had to reverse engineer the meaning of some phase options
which predated any of the current Soot maintainers, I wanted the
ability to compare the input to and output from each phase when
various phase options were specified. I found being able to see
Soot's representation of a method at arbitrary points very
useful. 

Since then, I've been involved a couple of times in trying to
diagnose errors that users have encountered when they ran Soot on
their own classes or on classes from third-party libraries to
which I do not have ready access.  I imagined that would have
been easier if I could have said "Run soot with '--dump-body all'
and send us the last jimple file produced before soot throws an
exception."  So I'm inclined to argue that we should not disable
--dump-body in the release.

--dump-cfg, unlike --dump-body,  might be of little use to people
who are not modifying the CFG classes (i.e. people other than
me).  I included it because I needed to examine the CFGs produced at
intermediate stages in Soot's processing of each method, rather
than just at the end after all transformations are complete.


You don't get the humongous output unless you specify --dump-cfg
and/or --dump-body options on the Soot command line (these are
documented; run "generate-tutorial" in the tutorial subdirectory
of your soot working directory, and look at
usage.{dvi,ps,pdf,html}). So I confess that I don't see why this
is major issue. I'm reminded of a very old joke: The doctor
raises his hands above his head and asks his patient, "Does it
hurt when you do this?" The patient tries and groans with pain,
"Yes, it does!"  The doctor replies, "Then don't do that."

Nevertheless, if you feel that the dumping options are likely to
cause more harm than good in their current form, I'd be glad to
hear why.  Presumably your suggested logging framework would
provide more fine-grained control over what gets recorded.  That
would certainly be a good idea, but I'm not sure who would be
interested in implementing it.

I have, though, removed some of the chatter from the graph
dumping code (it used to throw and immediately catch an
artificial exception to manufacture a stack trace if a graph
was constructed while no identifiable phase was running).  I'll
wait for feedback on the next paragraph before committing that
change.

Now for a point that will only be of interest to current Soot
maintainers. Currently the dumping code is conditional on DEBUG
flags in the CFG constructors, soot.Pack, and soot.Transform.
Since I added documentation describing the dumping code to
soot_options.xml, the DEBUG flags are probably a mistake: options
documented for users should not be conditional on DEBUG options.
So we should either make the dumping options official and remove
the DEBUG flags, or remove the user-visible documentation. I have
no strong preference, and will follow the consensus.

This is exactly where you would want a logging framework instead of an "ad-hoc" debugging framework. I call it ad-hoc as I and my collegues share "been-there-and-done-that" about this sort of issue and this is when we moved towards logging framework. I am not asking you to write one; instead I am asking you to choose one from JDK 1.4, log4j, or commons logging, etc.

That said, on the more pressing issue of "dump-XXXX" flags. What happens when I do not specify any "--dump-XXXX" options? I expect none of the dumps to happen. However, this is not the case. The dumps are attempted when I drive soot from an application. This is something a user (I) does not expect or desire, especially for debug outputs. Instead, it is usual for none or minimal options to be turned on in a library code and expecting the user to turn on the rest depending on his/her needs.

Contrary to you belief, I think that debug outputs should be disabled by default in production releases. These outputs should occurr under buggy circumstances and this is hard to achieve. Instead another option is to use a logging framework in such a way that the user can enable the use of the logging framework in the software. In doing so, on encountering a failure, the user can enable the logging framework, run the application, and send the dump to you. This is the approach we have been using.

While on this issue, the build file balks with a duplicate class error as the Options java files exist in both generated and soot directories. Interesting, these files differ considerably. After some searching it seems the ones in generated directory are more recent than those in soot directory. I am assuming that options are generated on the fly. If so, why do the same options java file exist in soot directory? I had to copy the generated files over the soot files and modify build.xml to get soot to compile.

Any idea when these issues would be resolved?

waiting for reply,

--

Venkatesh Prasad Ranganath,
Dept. Computing and Information Science,
Kansas State University, US.
web: http://www.cis.ksu.edu/~rvprasad