I'm running multiple ORB instances (each with different properties) within a single JVM. The differnt ORB instances are initialized in parallel on multiple threads. All goes well until today where I got a NullPointerException during orb initialization: java.lang.NullPointerException at org.omg.CONV_FRAME.CodeSetComponentHelper.write(CodeSetComponentHelper.java:68) at org.omg.CONV_FRAME.CodeSetComponentInfoHelper.write(CodeSetComponentInfoHelper.java:68) at org.jacorb.orb.standardInterceptors.CodeSetInfoInterceptor.<init>(CodeSetInfoInterceptor.java:57) at org.jacorb.orb.standardInterceptors.IORInterceptorInitializer.post_init(IORInterceptorInitializer.java:61) at org.jacorb.orb.ORB.interceptorPostInit(ORB.java:2147) at org.jacorb.orb.ORB.internalInit(ORB.java:2005) at org.jacorb.orb.ORB.set_parameters(ORB.java:1953) at org.omg.CORBA.ORB.init(ORB.java:251) After some digging in the code, I've found out that the problem lies in org.jacorb.orb.giop.CodeSet's method "getLocalCodeSetComponentInfo" which is not correctly implemented for concurrent access: In this method a first thread can have created "localCodeSetComponentInfo" but not filled in the field "ForCharData" yet and a second thread can then return this half initialized "localCodeSetComponentInfo" object as the first check on "localCodeSetComponentInfo" being null is not within the synchronized block.
Yes this does look possible. Are you able to reproduce it easily as a test case?
Hopefully fixed by SHA 1a0a0c8a3fa9cc27d5c2929ff86101d5f06187e2