• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Won't Fix
  • teck
  • Reporter: foshea
  • September 16, 2008
  • 1
  • Watchers: 2
  • September 18, 2008
  • September 18, 2008

Attachments

Description

infact i came across a strange issue, where two threads have locked same object.. pls see the below jstack, i got

“TP-Processor386” daemon prio=10 tid=0x5de48e20 nid=0x1852 waiting for monitor entry [0x5afba000..0x5afbb570] java.lang.Thread.State: BLOCKED (on object monitor) at com.tc.object.ClientObjectManagerImpl.basicLookup(ClientObjectManagerImpl.java:852)

  • locked <0x64308d40> (a com.tc.object.util.IdentityWeakHashMap) at com.tc.object.ClientObjectManagerImpl.lookupExistingOrNull(ClientObjectManagerImpl.java:394) at com.tc.object.bytecode.ManagerImpl.lookupExistingOrNull(ManagerImpl.java:641) at com.tc.object.bytecode.ManagerUtil.lookupExistingOrNull(ManagerUtil.java:251)

“TP-Processor51” daemon prio=10 tid=0x5d592d70 nid=0x44e4 waiting for monitor entry [0x59b5b000..0x59b5d570] java.lang.Thread.State: BLOCKED (on object monitor) at com.tc.object.ClientObjectManagerImpl.basicLookup(ClientObjectManagerImpl.java:852)

  • locked <0x64308d40> (a com.tc.object.util.IdentityWeakHashMap) at com.tc.object.ClientObjectManagerImpl.lookupExistingOrNull(ClientObjectManagerImpl.java:394) at com.tc.object.bytecode.ManagerImpl.lookupExistingOrNull(ManagerImpl.java:641) at com.tc.object.bytecode.ManagerUtil.lookupExistingOrNull(ManagerUtil.java:251)

while other threads are waiting for this lock

“TP-Processor356” daemon prio=10 tid=0x5d3f72f0 nid=0x7c76 waiting for monitor entry [0x57eb9000..0x57ebb4f0] java.lang.Thread.State: BLOCKED (on object monitor) at com.tc.object.ClientObjectManagerImpl.basicLookup(ClientObjectManagerImpl.java:852)

  • waiting to lock <0x64308d40> (a com.tc.object.util.IdentityWeakHashMap) at com.tc.object.ClientObjectManagerImpl.lookupExistingOrNull(ClientObjectManagerImpl.java:394) at com.tc.object.bytecode.ManagerImpl.lookupExistingOrNull(ManagerImpl.java:641) at com.tc.object.bytecode.ManagerUtil.lookupExistingOrNull(ManagerUtil.java:251)

Can you pls look at this, as i feel this is a critical issue.

Comments

Tim Eck 2008-09-16

Can you also tell me which Operating system this is, and what your java command line is (in particular any -XX switches used)?

Tim Eck 2008-09-16

I’m going to file a bug with Sun about the reporting in the thread dumps. I can reproduce these seemingly incorrect stack traces pretty easily. Even though there are threads that say they both have the lock at the same time, I never see anything hang. Also of note if that you shouldn’t ever see two RUNNABLE threads that both hold the lock in the same heap dump

There is a bug in ConcurrentHashMap that makes these ManagerUtil.lookupExistingOrNull() calls much too frequently. Upgrading to 2.6.x of Terracotta will avoid this problem

hari prasad 2008-09-17

its on linux box..

and jvm args used are:

JAVA_OPTS=”$JAVA_OPTS ““-Xms768m -Xmx1280m -XX:-UseBiasedLocking -XX:NewSize=512 m -XX:MaxNewSize=512m -XX:SurvivorRatio=3 -XX:-UseAdaptiveSizePolicy -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime - XX:+HeapDumpOnOutOfMemoryError -Dnetworkaddress.cache.ttl=10 -Dnetworkaddress.ca che.negative.ttl=0 -Dsun.net.inetaddr.ttl=10 -Dsun.net.inetaddr.negative.ttl=0 - Dsun.net.client.defaultConnectTimeout=60000 -Dsun.net.client.defaultReadTimeout= 60000

Tim Eck 2008-09-18

Thanks for providing the jvm arguments although from what I’ve found it doesn’t look like that information is relevant.

The reporting of the multiple “- locked <0x64308d40>” in the thread dumps is misleading, but I don’t think there is anything to worry about here. There should only ever be one thread that is actually runnable, the other threads will report BLOCKED state. Running a test program I can get the same type of misleading “locked” statement in thread dumps. This happens *without* using Terracotta so if anything this is a sun bug. I have filed a bug with Sun actually but it is yet to be formally accepted in their database.

On a related notes, terracotta 2.5.2 has a bug in which causes excessive calls into com.tc.object.bytecode.ManagerUtil.lookupExistingOrNull() originating from ConcurrentHashMap. Terracotta 2.6 and greater does not have this issue.

Tim Eck 2008-09-18

This is a not TC bug

hari prasad 2008-09-18

Hi, so its good that you are able to reproduce this without Terracotta. Can you tell me how did you reproduce that, so that i get some idea..

Tim Eck 2008-09-18

I attached a program called Lock.java here. Running this program with a 1.6.0 VM on linux should let you observe the threads in unusual state. I tested with 1.6.0_04 and 1.6.0_07 and using a variety of VM switches and they all behaved the same.

Fiona OShea 2008-09-18

No fixed version as this is not a Terracotta Bug.