Hi, IBM has a 1.5 jvm out. It might be worth seeing if you get the same error with it.
Ed On Wednesday 24 May 2006 18:27, Matthew Toseland wrote: > Observe the two stack traces here: > http://amphibian.dyndns.org/argh.txt > > Look at PacketSender in both cases. There were some seconds between > them, but they're both the same. It has locked one lock, and it is > waiting for the other. The other lock is not held by any thread. > > This is accompanied by wierd symptoms: Every node is backed off because > of an AcceptedTimeout. > > In conclusion? The current 0.7 code triggers a JVM bug - at least on my > machine - which kills us. I've seen the same thing with logging. > > Any ideas for a way forward? Or any ideas for why I am wrong (I hope I > am)? This is consistent, I just did another one, many minutes later. It > always has: > > "PacketSender thread for 0" daemon prio=1 tid=0x0825bbd8 nid=0x8c0 > waiting for monitor entry [0xb11ff000..0xb11ff5c0] > at freenet.node.KeyTracker.getNextUrgentTime(KeyTracker.java:790) > - waiting to lock <0x7ef4d718> (a > freenet.support.UpdatableSortedLinkedListWithForeignIndex) > at freenet.node.PeerNode.getNextUrgentTime(PeerNode.java:641) > - locked <0x7e129c78> (a freenet.node.PeerNode) > at freenet.node.PacketSender.realRun(PacketSender.java:85) > at freenet.node.PacketSender.run(PacketSender.java:47) > at java.lang.Thread.run(Thread.java:595) > > And in all 3 cases, (and with the same problem with logging earlier), > 0x7ef4d718 is not locked by any thread. > > And it's not looping; it's the same lock it's trying to get, and the > same lock it's got already, in all 3 cases. > > This is with sun java 1.5.0_06.
