[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] [Commented] (BCEL-267) Race conditions on static fields in BranchHandle and InstructionHandle
From:       "Stephan Herrmann (JIRA)" <jira () apache ! org>
Date:       2015-09-29 22:12:04
Message-ID: JIRA.12901414.1443557562000.107425.1443564724196 () Atlassian ! JIRA
[Download RAW message or body]


    [ 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)


[prev in list] [next in list] [prev in thread] [next in thread]