new search facility... thoughts?

I'm going to enter this as an RFE but I thought I'd first ask to see if it's already there. I thought perhaps 'structural search' might be it, but it doesn't seem to do what I need.

What I'm looking for is a way to search an execution path. Or, actually, all potential execution paths from a given point.

My use-case is that I suspect that a reference counter is being incremented more than it is being decremented (so the object isn't released from it's pool). So I'd like the ability to search the part of the code that I have narrowed the problem to, to see all the places that the increment counter method is called to see if there's a chance that the code may then erroneously skip the corresponding decrement method.

I can't achieve the same end with breakpoints as this error only occurs very sporadically (and only in production of course).

So, the idea to have a Search Execution Paths option would be very useful for me.

Is there anyway to do this today?

7 comments


I don't believe there is any way to do this in the product today. One possible answer is something that I'm playing around with is a generic "paired operations" inspection. It would allow you to specify a pairs of method calls, the first element of which must occur in a "try" block, and the second of which must occur in a corresponding "finally" block. In this case, the inspection would be triggered if the increment and decrement weren't paired. Not foolproof, but pretty close. Other examples include opening and closing I/O streams and JDBC connections. Making the inspection flexible enough to be useful is proving challenging, however. Expect it in an early Irida EAP.

--Dave Griffith

0

one thing it wouldn't do would be confirm a 1:1 ratio (from my understanding of what you're saying). But it sounds like a useful inspection nonetheless.

0


Correct. If you incremented twice in the same try block or decremented twice in the finally block it wouldn't trigger. My gut feel is that that sort of error is much less common than cases where things are correctly paired, but not wrapped in try/finally, and so may become mismatched on exceptional failure.

--Dave Griffith

0

alan brown wrote:

What I'm looking for is a way to search an execution path. Or, actually, all potential execution paths from a given point.


The method call hierarchy pane lets you see which methods may call your
method, and which methods might call them, and so on, with arbitrary
depth (just keep expanding nodes). Does this help or have I
misunderstood what you want?

0

Dave Griffith wrote:

In this case, the inspection would
be triggered if the increment and decrement weren't paired.


This would be extremely useful. I believe FindBugs does something
similar, though from the descriptions it sounds like it may use full
control flow analysis to test whether resources are released on all
paths out of a method rather than relying on method call pairing in
try/finally blocks.

0


Correct. Partially this is because FindBugs inspects byte code rather than source code, and there is no foolproof way of recreating try-catch-finally block structure from bytecode. More importantly, it's a difference in product vision. FindBugs basic goal is, well, finding bugs. InspectionGadgets takes a more proactive approach, with inspections that are as much about bug prevention and code maintainability as bug detection. Coding with a restrictive IG profile ends up creating code that is "way cleaner than it needs or deserves to be", as a friend of mine put it. It is hoped that the additional effort this involved is both minimized (via quick-fixes, refactoring triggers, and ease of navigation to errors) and pays off in the long run with decreased maintenance costs. It's also why I haven't worried too much about minimizing "false positives" in my inspections, something that FindBugs puts in a good deal of effort to do. For instance, if you're looking for real race condition bugs, it's worth doing some serious triage on variables accessed in both synchronized and unsynchronized contexts, and only report ones that look very suspicious. In IG, I just report all such variables, on the assumption that if they aren't a problem now, they probably will be in your project's future, and it's best to practice an ounce of prevention.

I should also note that shortly into the Irida EAP, I anticipate that the available IG rules will include everything FindBugs offers. Most of those rules are running on my machine now, and (yes) they've found a lot of bugs.

--Dave Griffith

0

It doesn't really do what I need as it's kind of a backwards method of searching. However, in many cases it is a tool to let me get at what I want, as long as what I want is to search for a method's usage, which I guess it probably always will be. On the downside, if it's a very common method, the results may not be very helpful due to the signal/noise ratio.

0

Please sign in to leave a comment.