For some strange reasons, that I'm looking for since several months, this occurs due to an internal exception when building QRP tables. The QRP table is dropped or marked incomplete by the recipient.

Another bug is caused the first time a Shareaza node enters to a LimeWire UltraPeer with its 1MBit table (apparently there's a transient problem that causes its table not being resized before computing the intra-QRP table, and there are attempt to patch bits after the last one 65535 in the resized table.) This bug is more common, but may affect the intra QRP table that your should have received.

In your case, Et Voilà, this is probably what happens: this is a connection from UltraPeer to UltraPeer, which should join its Leaf-to-UP tables and a map of its local shared library to create a merged QRP table. If this exception occurs, the QRP table becomes resized despite is is still not complete and new patches are received from a Shareaza node connecting to the remote LimeWire.

This bug is more frequent, but I really can't understand why this can happen, given the code we have. My modified version of LimeWire detects it (attempt to patch bits number 65535..65599 in a 65536-bits QRP table), but I have still not found a reason for why such exception occurs.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml