commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephan Herrmann (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (BCEL-267) Race conditions on static fields in BranchHandle and InstructionHandle
Date Tue, 29 Sep 2015 22:12:04 GMT

    [ https://issues.apache.org/jira/browse/BCEL-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14936009#comment-14936009
] 

Stephan Herrmann commented on BCEL-267:
---------------------------------------

These fields are nothing but an attempt at optimization :)
Explicitly and unconditionally creating a new handle when one is needed does not break anything.

Let me explain more: in my use-case BCEL is invoked during class loading of an inherently
concurrent application: Eclipse. If client-side synchronization based on data is not sufficient,
then BCEL is DOA in this context.

By saying that BCEL is not intended for any multi-threaded use -- including concurrency with
100% data isolation -- you seem to be saying that BCEL is not intended for use in any Java
applications other than tools operating in batch mode. Is that the message?

> Race conditions on static fields in BranchHandle and InstructionHandle
> ----------------------------------------------------------------------
>
>                 Key: BCEL-267
>                 URL: https://issues.apache.org/jira/browse/BCEL-267
>             Project: Commons BCEL
>          Issue Type: Bug
>          Components: Main
>    Affects Versions: 5.2
>            Reporter: Stephan Herrmann
>
> I have observed race conditions causing NullPointerException like this
> {code}java.lang.NullPointerException
>         at org.apache.bcel.generic.InstructionList.getInstructionHandles(InstructionList.java:1021)
>         at org.apache.bcel.generic.InstructionList.findHandle(InstructionList.java:141)
>         at org.apache.bcel.generic.MethodGen.<init>(MethodGen.java:194)
> {code}
> In the debugger I could verify that concurrent access to the fields {{BranchHandle.bh_list}}
or {{InstructionHandle.ih_list}} can cause corruption of those lists.
> I succeeded to make the exception less frequent by adding synchronized blocks, but still
the exception could be observed. I concluded that for safe protection the fields would need
to be made volatile, which in the end might actually defeat their original purpose of optimization.
> I have since then run with a patched version of BCEL, where those static fields were
simply removed and new Handles were created on every request. This variant finally was free
of the race condition.
> Seeing activity towards a 6.0 release, I'd appreciate if this change could be incorporated.
> The original bug tracking my experiments can be found in Eclipse bugzilla: https://bugs.eclipse.org/344350
> The modified classes (based on 5.2) can be found here:
> - http://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/tree/plugins/org.eclipse.objectteams.otre/bcelpatchsrc/org/apache/bcel/generic



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message