DefaultEncoder deadlock

[GoogleCodeExporter]

What steps will reproduce the problem?

> > This is the code that we were using:
> >     public static String javaScriptEncode(String str){
> >         DefaultEncoder encoder = new DefaultEncoder();
> >         return encoder.encodeForJavaScript(str);
> >     }
> >
> > When two threads attept to instantiate the DefaultEncoder object at
> the same
> > time, one thread seems to wait indefinately, consuming all server
> CPU.  I am
> > not sure exactly where this happens in the OWASP code, but moving
the
> > instantiation of the DefaultEncoder to the class level seems to fix
> this
> > issue.  Please note that this was consuming CPU for other
> applications on
> > the same hardware we are on.

Original issue reported on code.google.com by planetlevel on 20 Dec 2008 at 2:30

[GoogleCodeExporter]

Confirmed - in ESAPI 1.4 the initialization hangs in a multithreaded 
environment. 
This is due to improper use of static collections from an instance constructor 
during
initialization.  If you use the DefaultEncoder standalone in very fast 
succession it
can deadlock. A test application has been added to the test cases to 
demonstrate.

http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/test/java/org/
owasp/esapi/reference/EncoderConcurrencyTest.java

Original comment by planetlevel on 20 Dec 2008 at 5:31

• Changed state: Accepted

[GoogleCodeExporter]

Fixed by moving initialization code into static initializers.

Original comment by planetlevel on 20 Dec 2008 at 5:32

• Changed title: DefaultEncoder deadlock
• Changed state: Fixed

[GoogleCodeExporter]

Which version is this fix available in? I compared last two versions and 
couldn't
find a fix for it. Any help would be appreciated. Thanks.

Original comment by lake...@gmail.com on 6 Nov 2009 at 1:14

[GoogleCodeExporter]

http://code.google.com/p/owasp-esapi-java/source/detail?r=408

Original comment by planetlevel on 7 Nov 2009 at 2:06