[jira] [Updated] (BCEL-15) JustIce Pass3bVerifier Verifies Exception Handlers too often

["Emmanuel Bourg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/BCEL-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Bourg updated BCEL-15:
-------------------------------

          Component/s:     (was: Main)
                       Verifier
          Description: 
While using the JustIce Verifier that is built into BCEL to investigate some issues with the Purifier project (a pure Java preverifier.  See
http://www.markcrocker.com/~mcrocker/Computer/Purifier/), I noticed that the internal state of JustIce occasionally disagreed with the StackMaps produced by Sun's preverifier.

The problem seems to be that JustIce considers Exception handlers to be possible successors for EVERY instruction in a try block that result in merge changes when the outgoing frame is merged with the incoming frame of the first instruction in the Exception handler.

I believe that this is an overly broad interpretation of the specification. 
Only instructions that can actually throw the type (or subtype) of Exception that a handler is designed to catch should be considered to have possible a successor of the handler.

An excruciatingly detailed report with source code, bytecode and Data Flow Analysis can be found at:
http://www.markcrocker.com/~mcrocker/Computer/Purifier/justIceExceptionHandlingIssue.shtml

The solution would be to check if an instruction can throw the type of Exception that the handler can catch BEFORE checking to see if a merge causes a change. This would probably be a fairly involved task.

  was:
While using the JustIce Verifier that is built into BCEL to investigate some
issues with the Purifier project (a pure Java preverifier.  See
http://www.markcrocker.com/~mcrocker/Computer/Purifier/), I noticed that the
internal state of JustIce occasionally disagreed with the StackMaps produced by
Sun's preverifier.

The problem seems to be that JustIce considers Exception handlers to be possible
successors for EVERY instruction in a try block that result in merge changes
when the outgoing frame is merged with the incoming frame of the first
instruction in the Exception handler.

I believe that this is an overly broad interpretation of the specification. 
Only instructions that can actually throw the type (or subtype) of Exception
that a handler is designed to catch should be considered to have possible a
successor of the handler.

An excruciatingly detailed report with source code, bytecode and Data Flow
Analysis can be found at:
http://www.markcrocker.com/~mcrocker/Computer/Purifier/justIceExceptionHandlingIssue.shtml

The solution would be to check if an instruction can throw the type of Exception
that the handler can catch BEFORE checking to see if a merge causes a change. 
This would probably be a fairly involved task.

             Priority: Minor
          Environment: URL: http://www.markcrocker.com/~mcrocker/Computer/Purifier/justIceExceptionHandlingIssue.shtml  (was: Operating System: All
Platform: All
URL: http://www.markcrocker.com/~mcrocker/Computer/Purifier/justIceExceptionHandlingIssue.shtml)
    Affects Version/s:     (was: unspecified)
             Priority:   (was: P5)
             Severity:   (was: enhancement)

> JustIce Pass3bVerifier Verifies Exception Handlers too often
> ------------------------------------------------------------
>
>                 Key: BCEL-15
>                 URL: https://issues.apache.org/jira/browse/BCEL-15
>             Project: Commons BCEL
>          Issue Type: Improvement
>          Components: Verifier
>         Environment: URL: http://www.markcrocker.com/~mcrocker/Computer/Purifier/justIceExceptionHandlingIssue.shtml
>            Reporter: Mark Crocker
>            Assignee: Apache Commons Developers
>            Priority: Minor
>
> While using the JustIce Verifier that is built into BCEL to investigate some issues with the Purifier project (a pure Java preverifier.  See
> http://www.markcrocker.com/~mcrocker/Computer/Purifier/), I noticed that the internal state of JustIce occasionally disagreed with the StackMaps produced by Sun's preverifier.
> The problem seems to be that JustIce considers Exception handlers to be possible successors for EVERY instruction in a try block that result in merge changes when the outgoing frame is merged with the incoming frame of the first instruction in the Exception handler.
> I believe that this is an overly broad interpretation of the specification. 
> Only instructions that can actually throw the type (or subtype) of Exception that a handler is designed to catch should be considered to have possible a successor of the handler.
> An excruciatingly detailed report with source code, bytecode and Data Flow Analysis can be found at:
> http://www.markcrocker.com/~mcrocker/Computer/Purifier/justIceExceptionHandlingIssue.shtml
> The solution would be to check if an instruction can throw the type of Exception that the handler can catch BEFORE checking to see if a merge causes a change. This would probably be a fairly involved task.



--
This message was sent by Atlassian JIRA
(v6.2#6252)