[FB-Discuss] OS_OPEN_STREAM_EXCEPTION_PATH not working?

Paul Rowe prowe2 at yahoo.com
Sat Apr 17 23:44:40 EDT 2004


Hi David;

  Thanks for your help.  I resurrected the Dragon Book
to help me get more familiar with the concepts that
are in the OpenStreamDetector.  

  As for your suggestion, I have already been through
all that, and I got all the output (Dataflow analysis,
CFG output, transfer function).  However, the output
does not make much sense to me.  The output is hard to
read because I don't really have the bytecode offsets,
instead I have BasicBlock numbers.  I need a way of
correlating the BasicBlock numbers with begin/end
bytecode offsets.  I will generate the output again
and study it closely.  I noticed that for some reason,
the state of the ResourceFrame goes from closed to
open_exception while in the finally block of the code
sample.  

  I tried to run the main method, but there appears to
be a bug.  I get a NullPointerException.  I will try
to get that info for you as well.  For now, I am just
running FB from the top because it appears the main
method is broken.  

--- David Hovemeyer <daveho at cs.umd.edu> wrote:
> Hi Paul,
> 
> Thanks for the report.  I should have some time next
> week to take
> a look at this problem (and the NPE problem you
> reported a while ago).
> 
> In case you are interested in doing more debugging
> (and I am
> impressed that you actually looked through the
> code):
> 
> A lot of the dataflow-based detectors (including
> FindOpenStream) have a
> main() method which runs a test driver.  For
> FindOpenStream, you invoke
> it as follows:
> 
>   java -Ddataflow.debug=true
> -Ddataflow.printcfg=true \
> 	edu.umd.cs.findbugs.detect.FindOpenStream \
> 	<class filename> <method name> <bytecode offset>
> 
> You need to have findbugs.jar and coreplugin.jar on
> your
> CLASSPATH.
> 
> The classfile and method name are for the method
> that is exhibiting
> the problem.  The bytecode offset is the instruction
> which creates
> the stream which is causing the problem, since there
> may be
> several streams created in the method.  (You
> generally have to use
> "javap -c" to find the one that is causing the
> problem.)
> A stream creation point is a NEW instruction that
> creates
> a Stream, Reader, or Writer object.
> 
> The output is (eventually) a control flow graph for
> the method,
> where each instruction is annotated with a dataflow
> value.
> For FindOpenStream, the dataflow values are stack
> frames, where
> each frame slot is either the "instance" (the stream
> object
> being tracked) or "not the instance" (some other
> value).
> These show up as "I" and "-" characters,
> respectively.
> Local  variables are at the beginning of the frame,
> and operand stack slots follow the locals.
> In addition, each dataflow value records the status
> of the
> object being tracked, which can be "escaped",
> "open",
> "open_exception", "closed", "created", or
> "nonexistent".
> 
> A report is issued by the detector if an "open" or
> "open_exception"
> dataflow value reaches the exit block of the control
> flow graph.
> 
> Eventually (after some manual tracing through the
> graph) you
> find the path where a mistake in the analysis has
> wrongly
> concluded that the instance remained open.
> 
> -Dave



	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash



More information about the Findbugs-discuss mailing list