Name: gm110360 Date: 02/21/2003


FULL PRODUCT VERSION :
java version "1.4.0"

all OSes



A DESCRIPTION OF THE PROBLEM :
The methodname + args -> java.lang.reflect.Method cache
used by java.beans.Statement can throw
NullPointerExceptions when different instances of Statement
are being used concurrently (and also rarely even
functions). Here's how:

java.beans.XMLDecoder calls Statement.setCaching(true) in
its constructor (line 83).

It calls Statement.setCaching(false) in its close() method
(line 107).

The call the SAXParser.parse method eventually results in
java.beans.Statement.getMethod being called.
Statement.getMethod looks like this (355-371):

    static Method getMethod(...) {
        if (!isCaching()) {
            return findMethod(...);
        }
... now hits the cache.

    }

Because there's no synchronization, it's quite possible for
caching to be turned off in between the call to isCaching
and the calls to hit the cache. The following lines from
java.beans.Statement (373-379) confirm this:

    static void setCaching(boolean b) {
        methodCache = b ? new HashMap() : null;
    }

    private static boolean isCaching() {
        return methodCache != null;
    }

Furthermore, because methodCache is set to null when
caching is turned off, getMethod will throw a
NullPointerException when it accesses it. A less serious
(but still embarrassing) side effect is even when not using
XMLDecoders concurrently, that the cache will last, at
most, for one parser before being thrown away (by the call
to setCaching(false) in the close() method).


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
run code below.

EXPECTED VERSUS ACTUAL BEHAVIOR :
On my single processor NT machine, this prints out
NullPointerException every now and again (maybe once a
minute). Looks like this is being printed out by the
ExceptionListener inside java.beans.Statement, but it
doesn't occur under my debugger so can't confirm that. I
expect that running it on a multi-processor machine, or an
OS with finer grained context switching would produce the
error more often. If I get time, I'll confirm.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.NullPointerException
Continuing ...

This bug can be reproduced often.

---------- BEGIN SOURCE ----------
import java.beans.XMLDecoder;
import java.beans.XMLEncoder;
import java.io.*;

public class XMLDecoderTest {
  static void runtest(final byte[] buffer, int numthreads){
    for(int i = 0; i < numthreads; i++){
      new Thread(new Runnable(){
        public void run(){
          decode(buffer);
        }
      }).start();
    }
  }

  static void decode(byte[] buffer){
    for(int i = 0; i < 10000; i++){
      XMLDecoder d = new XMLDecoder(new ByteArrayInputStream(buffer));
      Object o = d.readObject();
      d.close();
    }
  }

  public static void main(String[] args)throws Exception{
    Object o = new TestObject("hello");
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    XMLEncoder e = new XMLEncoder(baos);
    e.writeObject(o);
    e.close();
    byte[] buffer = baos.toByteArray();
    runtest(buffer, 10);
  }

  public static class TestObject{
    String name;
    TestObject(String name){
      this.name = name;
    }
    public TestObject(){}
    public String getName(){return name;}
    public void setName(String name){this.name = name;}
  }
}


---------- END SOURCE ----------

CUSTOMER WORKAROUND :
hack the rt.jar to replace it with something sensible :-)

maybe more practically, could put a wrapper around
XMLDecoder to ensure that not used concurrently. This is
hard to do in practise, however, as could be being used by
a third party library.
(Review ID: 145798)
======================================================================