Hi Tim, I committed your suggestion of printing out the Throwable class name during construction to the repo, it can be enabled by setting the "tc.debug.throwable.construction" system property when the bootjar is created.
Your tip of using –Xverify:all did the trick for me and pointed out a problem in the bytecode that I generated. Thanks! Geert On 21 Sep 2007, at 19:44, Tim Eck wrote: > Sounds like you already tried some of the things I would first > suggest (different OS and VM combinations)…too bad that isn’t > offering up any more clues. > > > > If you comment out the call to Security.getProviders() in > ClassProcessorHelper.<clinit>, things might get a little further > and maybe the real problem will reveal itself. > > > > Another random stab in the dark would be to put some printing in > various interesting places. You can litter the (IFI) constructor of > ConcurrentHashMap to narrow down which code is problematic. It’s > probably either the new Segment[] (which is probably some sort of > class related issue), or trying to run the Segment.<init>. Other > places to add printing might be in the constructors of some key > exception types (NullPointerException, ClassNotFoundException, > NoClassDefFoundError, ClassFormatError, ClassCastException, etc). > Actually, maybe just adding some printing in Throwable’s > constructors that print getClass() might be the easiest approach. > For printing during early VM startup, I recommend > sun.misc.MessageUtils.toStderr(String). > > > > Finally trying –Xverify:all might tell ya something, and perhaps > running CheckClassAdapter on your new instrumentation might help > > > > Happy hunting > > -tim > > > > > > From: [EMAIL PROTECTED] [mailto:tc-dev- > [EMAIL PROTECTED] On Behalf Of Geert Bevin > Sent: Friday, September 21, 2007 9:01 AM > To: [email protected] > Subject: [tc-dev] Fishing for thoughts on JVM crash > > > > Hi, > > I'm working on improving the support for ConcurrentHashMap so that > locking is better optimized and that read locks are used when > appropriate. To do this, ConcurrentHashMap$Segment should extend > ReentrantReadWriteLock instead of the current ReentrantLock. However, > when I simply rewrite the Segment class to extend > ReentrantReadWriteLock and add the appropriate methods, I get a JVM > crash. I started to investigate, and this crash doesn't happen if I > continue to extend ReentrantLock and instead create a local var in > the Segment class for the ReentrantReadWriteLock and delegate all the > methods of ReentrantLock to the local variable. The locking wasn't > working yet (since the applicators had to be changed accordingly), > but at least the JVM wasn't crashing anymore. However, it feels quite > dirty to continue to be extending ReentrantLock just to prevent the > JVM from crashing. I tried searching through the source code and the > classes in the bootjar for references to the CHM segments that might > explicitly cast to ReentrantLock, but I couldn't find any. > > I thus tried to duplicate the public interface of ReentrantLock as > much as possible through method stubs (see attached diff). Even when > I implement all the interfaces that ReentrantLock implements and add > the required methods, I get a JVM crash when having a CHM$Segment > class that only extends java.lang.Object (see attached crash log). It > seems that during class loading, the JVM is using a CHM for the > verification of the security domain, and then executes some JVM code > during the constructor of CHM which causes the crash. Now I can't > find anything in the CHM constructor, nor with Jad or javap that > looks fishy. I also tried with different JVMs (MacOSX - simply prints > 'Bus error' and Linux - at least gives the crash log) and different > versions (1.5 and 1.6) to see if I could get more info, but nothing > changes. > > Does anyone have any ideas? If you want to duplicate this, apply the > diff to trunk, generate a bootjar, and execute any main class with > the bootjar after the java command, no need to specify anything TC > related (java -Xbootclasspath/p:/path/to/dso-boot-xyz.jar your.Main). > > Thanks for any insights that you can provide. > > Take care, > > Geert > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
