gtk-gnutella-devel Digest, Vol 33, Issue 1
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 33, Issue 1
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: iconv avec ennui. (Bill Pringlemeir) 2. DHT connection & bandwidth (Matthew Lye) 3. Re: DHT connection & bandwidth (Raphael Manfredi) 4. Re: DHT connection & bandwidth (Raphael Manfredi) 5. crash if you set listen port to 0 (jasen_betts@...) 6. Re: crash if you set listen port to 0 (Raphael Manfredi) 7. gtk-related crash (Meelis Roos) 8. valgrind (Jasen Betts) ---------------------------------------------------------------------- Message: 1 Date: Fri, 25 Sep 2009 12:34:16 -0500 From: Bill Pringlemeir <bpringle@...> Subject: Re: [gtk-gnutella-devel] iconv avec ennui. To: Raphael_Manfredi@... (Raphael Manfredi) Cc: gtk-gnutella-devel@... Message-ID: <87eipvapyf.fsf@...> Content-Type: text/plain; charset=us-ascii On 24 Sep 2009, Raphael_Manfredi@... wrote: > You are pinpointing a lack of granularity in the "shared" library files that > causes too much unnecessary stuff to be loaded due to transitive dependencies. > A first solution is therefore to start moving h_strconcat() and h_strdup() > out of misc.c, and then things should be much more under control. If these are useful (to have a locale aware variants), then you can use function pointers to have default stdc versions and allow the GUI front end to replace the function pointers with the locale aware versions during start up. This solves the linkage requirements and makes the library useful for non-glibc/iconv situation (perhaps certain headless configurations), while not depleting the locale aware variants that might be useful for more sane handling of file names and meta data which is certainly a strength of gtkg for non-English users. Fwiw, Bill Pringlemeir. ------------------------------ Message: 2 Date: Wed, 7 Oct 2009 09:42:53 -0400 From: Matthew Lye <mlye@...> Subject: [gtk-gnutella-devel] DHT connection & bandwidth To: gtk-gnutella-devel@... Message-ID: <BF2167D9-8E0A-4138-B0E3-10DA9660B500@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes The distributed hash table seems to be disregarding the connection status of GTKG in at least some cases; I found my Gnutella I/O maintaining rates of approximately 20 Kb/s both ways after disconnecting yesterday, which was somewhat disconcerting. Either the bandwidth meter is misrepresenting the impact of the DHT, or the DHT is providing enough of a load that monitoring and control should probably be provided. ------------------------------ Message: 3 Date: Wed, 7 Oct 2009 20:08:22 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] DHT connection & bandwidth To: gtk-gnutella-devel@... Message-ID: <haisfm$25a$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel: :The distributed hash table seems to be disregarding the connection :status of GTKG in at least some cases; I found my Gnutella I/O :maintaining rates of approximately 20 Kb/s both ways after :disconnecting yesterday, which was somewhat disconcerting. Either the :bandwidth meter is misrepresenting the impact of the DHT, or the DHT :is providing enough of a load that monitoring and control should :probably be provided. There is no way to control incoming UDP traffic from the DHT, due to the connection-less nature of UDP. As far as outgoing bandwidth goes, gtk-gnutella can emit more than the configured Gnutella bandwidth whenever the UDP queue enters flow-control. This is because, as you have noticed, DHT traffic can be quite heavy and it happens to also be extremely time-sensitive (since operations are handled as Remote Procedure Calls: every request expects a timely answer). There is no such thing as "disconnecting from the DHT". Whenever you turn off Gnutella traffic, you're still "connected" to the DHT and keep exchanging messages. What's probably misleading is that the DHT traffic is accounted as Gnutella traffic in the GUI. In as sense, this is not wrong since Gnutella messages are used. However, it is not trivial to account DHT traffic separately due to the way bandwidth is accounted for today, or I would have already done it. It's not extraordinary difficult either, so if you want to dive into the code and supply a patch, I'm always open to that kind of contribution. In the "future", there will be a "degraded" DHT mode whereby you can shield yourself from incoming traffic but can still query and publish to the DHT. I have not implemented this logic yet. Raphael ------------------------------ Message: 4 Date: Sat, 17 Oct 2009 11:03:28 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] DHT connection & bandwidth To: gtk-gnutella-devel@... Message-ID: <hbc8a0$tr9$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel: :Either the bandwidth meter is misrepresenting the impact of the DHT, or the :DHT is providing enough of a load that monitoring and control should :probably be provided. This is now implemented in r17082. DHT traffic is inherently variable, but can be quite high if you're looking or storing a lot of entries: basically you're performing lookups for the files you have in your download queue + all the files you're sharing. On my node here, the DHT outgoing traffic is about 34 KiB/s on average, but it can peak to much higher values. To be a useful DHT node, you should probably allow at least 20 KiB/s of outgoing DHT traffic, or leave its traffic uncapped (which is what I do here). Raphael ------------------------------ Message: 5 Date: Wed, 14 Oct 2009 00:54:41 +1300 From: jasen_betts@... Subject: [gtk-gnutella-devel] crash if you set listen port to 0 To: gtk-gnutella-devel@... Message-ID: <20091013115441.GA26414@...> Content-Type: text/plain; charset=us-ascii revision 17067 setting listen_port to 0 with the 'preferences window' or the shell command line causes an assertion failure not sure how to build debug symbols for debian. depending on what I do I get this with closing the preferences window: FATAL: Assertion failure in mq.c:754: "l->data != NULL" CRASH (pid=32029) by SIGABRT Aborted or this with changing tabs in the preferences window or using the shell: WARNING: Assertion failure in udp.c:305: "n" WARNING: Assertion failure in udp.c:305: "n" WARNING: Assertion failure in udp.c:305: "n" ** ERROR **: unexpected address in pmsg_write_ipv4_or_ipv6_addr(): <none> aborting... CRASH (pid=32025) by SIGABRT Aborted I also got this one once FATAL: Assertion failure in mq.c:320: "n == q->count" CRASH (pid=32231) by SIGABRT and once it seemed to work... but produced lots of WARNING: Assertion failure in udp.c:305: "n" WARNING: Assertion failure in udp.c:305: "n" WARNING: Assertion failure in udp.c:305: "n" WARNING: Assertion failure in udp.c:305: "n" WARNING: Assertion failure in udp.c:305: "n" bye. ------------------------------ Message: 6 Date: Fri, 23 Oct 2009 17:42:49 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] crash if you set listen port to 0 To: gtk-gnutella-devel@... Message-ID: <hbspup$vnn$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting jasen_betts@... from ml.softs.gtk-gnutella.devel: :setting listen_port to 0 with the 'preferences window' or the :shell command line causes an assertion failure I made a fix in SVN 17111 that may work for you. Difficult to say without a stack trace. Raphael ------------------------------ Message: 7 Date: Thu, 29 Oct 2009 10:25:53 +0200 (EET) From: Meelis Roos <mroos@...> Subject: [gtk-gnutella-devel] gtk-related crash To: gtk-gnutella-devel@... Message-ID: <alpine.SOC.1.00.0910291014380.24781@...> Content-Type: TEXT/PLAIN; charset=US-ASCII After 45 days of uptime I got this crash in search results view (no search sidebar). I saw the results, scrolled down and I think I managed to click Clear or hit Alt-C to clear this search results. Debian etch, gtk-gnutella/0.96.7u-16967 (2009-08-23; GTK2; Linux i686) GLib 2.12.4 Gtk+ 2.8.20 GNU TLS 1.0.16 First I got this warning: (gtk-gnutella:8515): GLib-GObject-CRITICAL **: g_object_remove_weak_pointer: assertion `G_IS_OBJECT (object)' failed and right then a segfault: Program terminated with signal 11, Segmentation fault. #0 0xb7925314 in IA__g_object_remove_weak_pointer (object=0x1, weak_pointer_location=0x9db67e0) at gobject.c:1543 1543 gobject.c: No such file or directory. in gobject.c (gdb) bt #0 0xb7925314 in IA__g_object_remove_weak_pointer (object=0x1, weak_pointer_location=0x9db67e0) at gobject.c:1543 #1 0xb7bdd62b in queue_item_free (item=0x9db67e0) at gdkgeometry-x11.c:1025 #2 0xb7bdd7c7 in _gdk_window_process_expose (window=0x8d65668, serial=31487604, area=0xbfbcc4ec) at gdkgeometry-x11.c:1185 #3 0xb7bda456 in gdk_event_translate (display=0x83fe0a8, event=0x9c86558, xevent=0xbfbcc54c, return_exposes=0) at gdkevents-x11.c:1630 #4 0xb7bdab57 in _gdk_events_queue (display=0x83fe0a8) at gdkevents-x11.c:2225 #5 0xb7bdaebf in gdk_event_dispatch (source=0x8402e28, callback=0, user_data=0x0) at gdkevents-x11.c:2285 #6 0xb78aa771 in IA__g_main_context_dispatch (context=0x83c1380) at gmain.c:2045 #7 0xb78ad7e6 in g_main_context_iterate (context=0x83c1380, block=1, dispatch=1, self=0x83c3eb8) at gmain.c:2677 #8 0xb78adba7 in IA__g_main_loop_run (loop=0x90fbcc0) at gmain.c:2881 #9 0xb7d42281 in IA__gtk_main () at gtkmain.c:1003 #10 0x0818087e in main_gui_run (geometry_spec=0x0) at main.c:695 #11 0x08056531 in main (argc=1, argv=0xbfbcc834) at main.c:1616 -- Meelis Roos (mroos@...) ------------------------------ Message: 8 Date: Fri, 30 Oct 2009 00:01:22 +1300 From: Jasen Betts <jasen@...> Subject: [gtk-gnutella-devel] valgrind To: gtk-gnutella-devel@... Message-ID: <20091029110122.GA26669@...> Content-Type: text/plain; charset=us-ascii a patch to make gtk-gnutella behave better in valgrind so you can see the real undefined behavior Index: src/lib/entropy.c =================================================================== --- src/lib/entropy.c (revision 17133) +++ src/lib/entropy.c (working copy) @@ -146,9 +146,21 @@ } /* - * Add local CPU state noise. + * to test with valgrind define VALGRIND_MODE + * in the environment before executing it + * eg: + * + * $ VALGRIND_MODE=1 valgrind gtk-gnutella + * */ + + if(!getenv("VALGRIND_MODE")){ + + /* + * Add local CPU state noise. + */ + if (setjmp(env)) { /* We will never longjmp() back here */ g_assert_not_reached(); @@ -259,6 +271,7 @@ /* * Done, finalize SHA1 computation into supplied digest buffer. */ + } /* not VALGRIND_MODE */ SHA1Result(&ctx, digest); } =================================================================== -- ------------------------------ ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 33, Issue 1 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
