Bill Pringlemeir wrote: > [...] recursion detected (32232 already pending) > Assertion failure (oob.c:171) "!g_hash_table_lookup(results_by_muid, r->muid)"
> gtk-gnutella seems to be returning an OOB result to a BearShare > client. I think that the mq_udp_putq is showing a recursion count? > Perhaps the stack is smashed? I think the assertion failure is not directely related to the detected recursion. Albeit if messages are queued indefinitely as it seems to be the case here due to a bug, this would increase the likelyness for the assertion to trigger. I assume the assertion is just plain wrong because if the MUID expired or was explicitely removed (due to a disconnection) from the routing table, the MUID can appear again here - potentially from the reconnected node which re-issuing the query with same MUID as before. That is, we might still have OOB replies queued for this MUID. Therefore I made this assertion non-fatal for now. -- Christian ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
