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.
--
Matthew J Toseland - toad@???
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
