gtk-gnutella-devel Digest, Vol 25, Issue 2
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 25, Issue 2
by gtk-gnutella-devel-request
::
Rate this Message:
Send gtk-gnutella-devel mailing list submissions to
gtk-gnutella-devel@... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel or, via email, send a message with subject or body 'help' to gtk-gnutella-devel-request@... You can reach the person managing the list at gtk-gnutella-devel-owner@... When replying, please edit your Subject line so it is more specific than "Re: Contents of gtk-gnutella-devel digest..." Today's Topics: 1. Re: assertion failure in routing.c:767 (Raphael Manfredi) 2. Re: assertion failure in routing.c:767 (Raphael Manfredi) 3. Re: assertion failure in routing.c:767 (Meelis Roos) 4. Does gtk-gnutella (also) use OpenSSL? (gionnico) 5. Re: Does gtk-gnutella (also) use OpenSSL? (Christian Biere) 6. DHT uptime. (Bill Pringlemeir) 7. [was: DHT uptime.] (Bill Pringlemeir) 8. Re: [was: DHT uptime.] (Raphael Manfredi) 9. Re: [was: DHT uptime.] (Christian Biere) 10. Re: [was: DHT uptime.] (Raphael Manfredi) ---------------------------------------------------------------------- Message: 1 Date: Tue, 9 Sep 2008 12:24:43 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] assertion failure in routing.c:767 To: gtk-gnutella-devel@... Message-ID: <ga5pub$ta5$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Meelis Roos <mroos@...> from ml.softs.gtk-gnutella.devel: :15381 does not fix it either. What is your operating system and which version? Raphael ------------------------------ Message: 2 Date: Tue, 9 Sep 2008 12:49:33 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] assertion failure in routing.c:767 To: gtk-gnutella-devel@... Message-ID: <ga5rct$1sg$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Meelis Roos <mroos@...> from ml.softs.gtk-gnutella.devel: :15381 does not fix it either. Can you let me know where 15832 fails exactly? Raphael ------------------------------ Message: 3 Date: Tue, 9 Sep 2008 22:48:17 +0300 (EEST) From: Meelis Roos <mroos@...> Subject: Re: [gtk-gnutella-devel] assertion failure in routing.c:767 To: gtk-gnutella-devel@... Message-ID: <Pine.SOC.4.64.0809092246340.7940@...> Content-Type: TEXT/PLAIN; charset=US-ASCII Debian 4.0 (etch) on i386. Hmm, 15832 works! -- Meelis Roos (mroos@...) ------------------------------ Message: 4 Date: Thu, 11 Sep 2008 14:49:27 +0200 From: gionnico <gionnico@...> Subject: [gtk-gnutella-devel] Does gtk-gnutella (also) use OpenSSL? To: gtk-gnutella-devel@... Message-ID: <200809111449.27210.gionnico@...> Content-Type: text/plain; charset="iso-8859-1" I use gtk-gnutella in gentoo - I've got a personal svn ebuild overlay. I see there are some "use flags", and one of those is gnutls. I know gnutls is the alternative to OpenSSL (which is usually preferred). So, can gtk-gnutella use OpenSSL if I don't enable "gnutls" or it wont have encryption support at all? The flag in build.sh is: "--disable-gnutls". -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Comunicazione NON verbale: impara il linguaggio del corpo e ottieni * successo nella vita e negli affari Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8252&d=11-9 ------------------------------ Message: 5 Date: Thu, 11 Sep 2008 15:47:06 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Does gtk-gnutella (also) use OpenSSL? To: gtk-gnutella-devel@... Message-ID: <20080911134706.GA1429@cyclonus> Content-Type: text/plain; charset=utf-8 gionnico wrote: > I know gnutls is the alternative to OpenSSL (which is usually preferred). > So, can gtk-gnutella use OpenSSL if I don't enable "gnutls" No. > or it wont have encryption support at all? Without GNU TLS you won't have any encryption at all. > The flag in build.sh is: "--disable-gnutls". Not a good idea because encryption is almost mandatory in the Gnutella network. You risk throttling and blocking a la Comcast. -- Christian ------------------------------ Message: 6 Date: Sat, 13 Sep 2008 09:35:16 -0500 From: Bill Pringlemeir <bpringle@...> Subject: [gtk-gnutella-devel] DHT uptime. To: gtk-gnutella-devel@... Message-ID: <87myicdsgr.fsf@...> Content-Type: text/plain; charset=us-ascii I had one headless node running for five days with DHT enabled. It had over 300 nodes connected for most of the time period. Rev 15830. fwiw, Bill Pringlemeir. ------------------------------ Message: 7 Date: Mon, 15 Sep 2008 12:00:11 -0500 From: Bill Pringlemeir <bpringle@...> Subject: [gtk-gnutella-devel] [was: DHT uptime.] To: gtk-gnutella-devel@... Message-ID: <871vzlny3o.fsf@...> Content-Type: text/plain; charset=us-ascii On 13 Sep 2008, bpringle@... wrote: > I had one headless node running for five days with DHT enabled. It > had over 300 nodes connected for most of the time period. Rev 15830. I am not quite capable of solving this one. The DHT lookup seems to have timed out, but the original lookup has been freed already. If we do an n-lookup and any of one the lookup succeeds, is the look up freed and then some latent lookup comes in with a timeout? I think that is the condition; very tricky. (gdb) where #0 0x4034e967 in sigsuspend () from /lib/libc.so.6 #1 0x0815ec30 in crash_handler (signo=6) at crash.c:173 #2 <signal handler called> #3 0x4034e566 in raise () from /lib/libc.so.6 #4 0x4034fd88 in abort () from /lib/libc.so.6 #5 0x08161e38 in assertion_failure (data=<value optimized out>) at fast_assert.c:96 #6 0x0814602b in lookup_value_delay (nl=0x421c9aa0) at lookup.c:191 #7 0x08147141 in lookup_value_rpc_cb (type=DHT_RPC_TIMEOUT, kn=0x4173a7c0, unused_n=0x0, function=0, payload=0x0, len=0, arg=0x408047a8) at lookup.c:2997 #8 0x08150be0 in rpc_timed_out (unused_cq=0x82dec40, obj=0x41fb8ab8) at rpc.c:155 #9 0x0815e3a4 in cq_expire (cq=0x82dec40, ev=0x0) at cq.c:446 #10 0x0815e51c in cq_clock (cq=0x82dec40, elapsed=<value optimized out>) at cq.c:497 #11 0x0815e614 in callout_timer (unused_p=0x0) at cq.c:567 #12 0x400a2a16 in g_source_get_current_time () from /usr/lib/libglib-2.0.so.0 #13 0x400a22f1 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #14 0x400a5983 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 #15 0x400a5ea2 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #16 0x0811f77a in topless_main_run () at topless.c:49 #17 0x0804e3eb in main (argc=6, argv=0xbfc82614) at main.c:1437 Sorry, I didn't have dht_*_debug flags set. As an aside, from a cursory glance, it seems that rpc_info and pmsg_info could be merged and this might simplify things. They have a circular reference, are always allocated together, and have 'nl' and lid elements refer to the same thing. Is this due to historic reasons or is the pmsg intended to persist while the rpc_info is gone during timeouts or something? Regards, Bill Pringlemeir. ------------------------------ Message: 8 Date: Tue, 16 Sep 2008 10:19:05 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] [was: DHT uptime.] To: gtk-gnutella-devel@... Message-ID: <gao16p$v7l$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Bill Pringlemeir <bpringle@...> from ml.softs.gtk-gnutella.devel: :I am not quite capable of solving this one. The DHT lookup seems to :have timed out, but the original lookup has been freed already. If we :do an n-lookup and any of one the lookup succeeds, is the look up :freed and then some latent lookup comes in with a timeout? I think :that is the condition; very tricky. I think the "lookup_value_delay(nl);" call should be enclosed in an else {} block related to the if() above. Can you double check your logs to see you have a "aborting secondary key fetch..." trace before the crash? (provided you had dht_lookup_debug set to a level greater than 1). Still, looking at the code quickly, I believe the else {} block is missing. Raphael ------------------------------ Message: 9 Date: Tue, 16 Sep 2008 15:04:45 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] [was: DHT uptime.] To: gtk-gnutella-devel@... Message-ID: <20080916130445.GA7624@...> Content-Type: text/plain; charset=utf-8 Raphael Manfredi wrote: > Quoting Bill Pringlemeir <bpringle@...> from ml.softs.gtk-gnutella.devel: > :I am not quite capable of solving this one. The DHT lookup seems to > :have timed out, but the original lookup has been freed already. If we > :do an n-lookup and any of one the lookup succeeds, is the look up > :freed and then some latent lookup comes in with a timeout? I think > :that is the condition; very tricky. > > I think the "lookup_value_delay(nl);" call should be enclosed in an else {} > block related to the if() above. > > Can you double check your logs to see you have a > > "aborting secondary key fetch..." > > trace before the crash? (provided you had dht_lookup_debug set to a level > greater than 1). > > Still, looking at the code quickly, I believe the else {} block is missing. I don't see what lookup_is_alive() is good for. It is not valid C if the pointer actually references a freed object as per C standard section 6.2.4. If you want to use weak references, look at core/nodes.c and "node_id". You have to use numeric IDs, not pointers to track objects beyond their life-cycle. -- Christian ------------------------------ Message: 10 Date: Tue, 16 Sep 2008 14:25:09 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] [was: DHT uptime.] To: gtk-gnutella-devel@... Message-ID: <gaofk5$8kv$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel: :I don't see what lookup_is_alive() is good for. It is not valid C if the :pointer actually references a freed object as per C standard section 6.2.4. If :you want to use weak references, look at core/nodes.c and "node_id". You have :to use numeric IDs, not pointers to track objects beyond their life-cycle. This code is perfectly valid as the pointer is used only as an integer here, as a key in the hash table, and is never de-referenced unless it is valid (presence in the table means the pointer is valid). Anyway, this is not the problem here. The problem is the missing else block, most probably. I need to review the code to make sure this was my original intent. One thing is sure: as written, this part of the code is broken and can lead to the assertion failure. Raphael ------------------------------ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 25, Issue 2 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
