gtk-gnutella-devel Digest, Vol 20, Issue 1
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 20, 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: gtk-gnutella crash (on missing font?) (Christian Biere) 2. Re: gtk-gnutella crash (on missing font?) (Meelis Roos) 3. Runned out of descriptors (gionnico) 4. Re: Runned out of descriptors (Christian Biere) 5. novel crash in 'real_sort_list()' (r15114, GTK1, Darwin ?/Leopard 10.5.2) (Matthew Lye) 6. Re: novel crash in 'real_sort_list()' (r15114, GTK1, Darwin ?/Leopard 10.5.2) (Christian Biere) 7. Re: Runned out of descriptors (Raphael Manfredi) 8. Re: novel crash in 'real_sort_list()' (r15114, GTK1, Darwin ?/Leopard 10.5.2) (Matthew Lye) 9. Re: BearShare is too aggressive or it's so widely spreaded? (Christian Biere) ---------------------------------------------------------------------- Message: 1 Date: Wed, 30 Jan 2008 16:23:47 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] gtk-gnutella crash (on missing font?) To: gtk-gnutella-devel@... Message-ID: <20080130152347.GF9398@cyclonus> Content-Type: text/plain; charset=us-ascii Meelis Roos wrote: > I looked over my search results and after clicking on Alt-C to clean > current search rulsts and the clicking on aother sear, the new search > did not appear and gtk-gnutella was hung for several seconds and then > crashed, with messages like this in parent terminal. Looks like a crash > from pango on missing Hangul font?? Running debian sarge with gtk2 and > pango from that era. > 08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory > Failed to load Pango module for id: 'HangulScriptEngineFc' You can probably trigger this by pasting text from here to the search bar: http://ko.wikipedia.org/wiki/%EA%B0%81%EB%8F%84 This looks like either a bug in Pango or a problem with your installation. You should upgrade Pango or install this missing module. -- 1000 octets = 1 ko = 1 kilooctet; 1024 octets = 1 Kio = 1 kibioctet 1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet 1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet ------------------------------ Message: 2 Date: Thu, 31 Jan 2008 16:46:58 +0200 (EET) From: Meelis Roos <mroos@...> Subject: Re: [gtk-gnutella-devel] gtk-gnutella crash (on missing font?) To: gtk-gnutella-devel@... Message-ID: <Pine.SOC.4.64.0801311646310.15933@...> Content-Type: TEXT/PLAIN; charset=US-ASCII It appears the distro was upgraded to debian etch while gtk-gnutella was running and pango was switched to new version. So this was a transient installation problem not specific to gtk-gnutella - thank you for the suggestions. When recompiled against new gtk and pango, it does not crash on Hangul. But my default window manager crashed - but that's another story :) -- Meelis Roos (mroos@...) ------------------------------ Message: 3 Date: Fri, 22 Feb 2008 13:22:08 +0100 From: gionnico <gionnico@...> Subject: [gtk-gnutella-devel] Runned out of descriptors To: gtk-gnutella-devel@... Message-ID: <47BEBE70.60302@...> Content-Type: text/plain; charset=ISO-8859-15; format=flowed If I download too many files (or better, I think sources), I get this warning, the queue frozens and download stops: what are these "descriptors"? How many are them, what does their number depend on and what is that percentile (25% @default) for? Thanks in advance. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Assicura le tue vacanze e settimane bianche in pochi click! * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7600&d=22-2 ------------------------------ Message: 4 Date: Fri, 22 Feb 2008 16:29:04 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Runned out of descriptors To: gtk-gnutella-devel@... Message-ID: <20080222152904.GI8053@cyclonus> Content-Type: text/plain; charset=us-ascii gionnico wrote: > If I download too many files (or better, I think sources), I get this > warning, the queue frozens and download stops: what are these "descriptors"? Have you increased the limit for simultaneous downloads? The default is 100 which should be fine. I would not set it higher than maybe ~250 even on a very fast connection because every connection adds overhead. You might have to increase your file descriptor process limit, if you increase this setting too much. A setting of 250 means, it will use up to 500 file descriptors (but only 251 if downloading a single file from 250 sources). If you have 300 leaves and 32 ultrapeers, that's already 832 but there might also be uploads and you need around 10 for logging and save files. The default for banning file descriptors seems to be 25% (which means 256 for a common limit of 1024 file descriptors per process on Linux-based systems), so you might run out of file descriptors. In your shell, run ulimit -n to check your file descriptor limit per process. You could increase it to 2048 to be safe in the above mentioned case. Increasing this resource limit requires root privileges usually. Otherwise don't increase the limit for simultaenous downloads above 100 or decrease the leave connection limit to 100-200 or even much less if you have little upload bandwidth (less than 256 kbit/s). LimeWire has a limit of 32 leaves for example but the more the merrier and efficient, it just needs more CPU and traffic. If you download mostly small files (less than 10 MiB), you could also decrease the limit for downloads per file because it's kind of nonsense to download a 4 MiB file from more than about a dozen sources. Thus you could decrease this limit from 40 to 10-20 to safe descriptors. This also allows you to download more files at a time, instead of one file with (too) many sources. It might especially help if there are many sources that just don't work. > How many are them, what does their number depend on and what is that > percentile (25% @default) for? It's the number of file descriptors used for banning. Banning means the connection will be hold (but ignored) until the remote side disconnects. This is useful to avoid reconnect overhead caused by peers which went haywire or hostile parties. It's not important though most of the time and you could safely decrease it even to zero, same goes for the reserved number of file descriptors. If you have a really low socket or file descriptor limit (less than 512) and no way to increase it, I would certainly do this. The default might be overkill anyway. -- 1000 octets = 1 ko = 1 kilooctet; 1024 octets = 1 Kio = 1 kibioctet 1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet 1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet ------------------------------ Message: 5 Date: Sun, 2 Mar 2008 06:30:53 -0500 From: Matthew Lye <mlye@...> Subject: [gtk-gnutella-devel] novel crash in 'real_sort_list()' (r15114, GTK1, Darwin ?/Leopard 10.5.2) To: gtk-gnutella-devel@... Message-ID: <FD289637-D0E2-4678-8D1D-049482FFE94E@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes I hadn't seen this before. I think that I'm looking at a failure to check a malloc'd pointer for NULL; am I correct? The circumstance was, that I had selected many contiguous 'incomplete' download entries, and then re-sorted the list by clicking on the top of the 'progress' column. > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 > 0x005b2a70 in real_sort_list () > (gdb) bt > #0 0x005b2a70 in real_sort_list () > #1 0x001923a0 in on_clist_download_files_click_column > (clist=0x63bd930, column=2, unused_udata=<value temporarily > unavailable, due to optimizations>) at fileinfo.c:506 > #2 0x004e9a1c in gtk_handlers_run () > #3 0x004ea1ac in gtk_signal_real_emit () > #4 0x004eabc8 in gtk_signal_emit () > #5 0x004e9a1c in gtk_handlers_run () > #6 0x004ea1ac in gtk_signal_real_emit () > #7 0x004eabc8 in gtk_signal_emit () > #8 0x005d5fcc in gtk_real_button_released () > #9 0x004e9d40 in gtk_signal_real_emit () > #10 0x004eabc8 in gtk_signal_emit () > #11 0x005d5bfc in gtk_button_button_release () > #12 0x00533284 in gtk_marshal_BOOL__POINTER () > #13 0x004e9eb0 in gtk_signal_real_emit () > #14 0x004eabc8 in gtk_signal_emit () > #15 0x0048c974 in gtk_widget_event () > #16 0x00535220 in gtk_propagate_event () > #17 0x005356d8 in gtk_main_do_event () > #18 0x00675238 in gdk_event_dispatch () > #19 0x006bdaa4 in g_main_dispatch () > #20 0x006bf164 in g_main_iterate () > #21 0x006bf4ac in g_main_run () > #22 0x00535b68 in gtk_main () > #23 0x0017001c in main_gui_run (geometry_spec=<value temporarily > unavailable, due to optimizations>) at main.c:692 > #24 0x00003de0 in main (argc=1, argv=0xbffff438) at main.c:1418 regards, Matthew Lye ------------------------------ Message: 6 Date: Sun, 2 Mar 2008 23:27:38 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] novel crash in 'real_sort_list()' (r15114, GTK1, Darwin ?/Leopard 10.5.2) To: gtk-gnutella-devel@... Message-ID: <20080302222738.GD18046@cyclonus> Content-Type: text/plain; charset=us-ascii Matthew Lye wrote: > I hadn't seen this before. I think that I'm looking at a failure to > check a malloc'd pointer for NULL; am I correct? NULL? Yes. malloc? No. > The circumstance was, that I had selected many contiguous 'incomplete' > download entries, and then re-sorted the list by clicking on the top > of the 'progress' column. > > Program received signal EXC_BAD_ACCESS, Could not access memory. > > Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 > > 0x005b2a70 in real_sort_list () > > (gdb) bt > > #0 0x005b2a70 in real_sort_list () > > #1 0x001923a0 in on_clist_download_files_click_column > > (clist=0x63bd930, column=2, unused_udata=<value temporarily > > unavailable, due to optimizations>) at fileinfo.c:506 I don't know why it would crash there or what's the NULL pointer doing there. If it's reproducable it might be worth looking at but it would also require more debug information. You can't even see which pointer is NULL here. -- 1000 octets = 1 ko = 1 kilooctet; 1024 octets = 1 Kio = 1 kibioctet 1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet 1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet ------------------------------ Message: 7 Date: Mon, 3 Mar 2008 15:12:08 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] Runned out of descriptors To: gtk-gnutella-devel@... Message-ID: <fqh4g8$rp8$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel: :It's the number of file descriptors used for banning. Banning means the :connection will be hold (but ignored) until the remote side disconnects. This :is useful to avoid reconnect overhead caused by peers which went haywire or :hostile parties. It's not important though most of the time and you could :safely decrease it even to zero, same goes for the reserved number of file :descriptors. If you have a really low socket or file descriptor limit (less :than 512) and no way to increase it, I would certainly do this. The default :might be overkill anyway. Note that when GTKG runs out of file descriptors, it attempts to close a pending banned conenction and retries the file descriptor allocation. When it can do that, you get a "yellow" warning. When there are no more banning descriptors to reuse and GTKG cannot allocate a file descriptor, you get the "red" warning. So you may leave the banning slots in place, they are not going to penalize you for their slots will be reused when GTKG needs to. Raphael ------------------------------ Message: 8 Date: Mon, 3 Mar 2008 12:24:58 -0500 From: Matthew Lye <mlye@...> Subject: Re: [gtk-gnutella-devel] novel crash in 'real_sort_list()' (r15114, GTK1, Darwin ?/Leopard 10.5.2) To: gtk-gnutella-devel@... Message-ID: <F14573CF-123A-413E-A8ED-E589BE4EEF62@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > I don't know why it would crash there or what's the NULL pointer doing > there. If it's reproducable it might be worth looking at but it would > also require more debug information. You can't even see which pointer > is NULL here. I'll give it a go, next time I'm running GTKG. Any requests, besides "bt full"? - Matt ------------------------------ Message: 9 Date: Sun, 9 Mar 2008 20:47:46 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] BearShare is too aggressive or it's so widely spreaded? To: gtk-gnutella-devel@... Message-ID: <20080309194746.GD6179@cyclonus> Content-Type: text/plain; charset=us-ascii Hauke Hachmann wrote: > On Thursday 10 January 2008, gionnico wrote: > > It's strange but every time I connect if I don't force any connection > > I find to be connected almost only to BearShare ultrapeers. > > > > And the cache becomes full of bearshare nodes. > > > > To avoid this I've had to set a 50% percentage in the connection > > setup for the allowed unique useragents. > > This makes a lot of hosts fail until it finds other nodes (usually > > LimeWire). > > I second that. Sometimes my client has so much trouble bootstrapping any > ultrapeers other than BearShare, that I manually help it by grepping my > local "ultras" file for hosts with port numbers other than 6346 or > 6348. This works, because BearShare is quite old-fashioned in > encouraging to use only these ports. > > As a "quick hack" mimicking this manual help, gtk-gnutella could do > something like "if the anti-monopoly feature is enabled and if the > ratio of a certain vendor is already maxed out, then only try to > connect to peers that have a port number that is not used by one of the > already connected peers of that vendor". This would do the trick for > the moment. I've added such a hack now but it looks like BearShare might not be the one to blame here. I think LimeWire fucked up on an EPIC level. Instead of sending proper negative responses, it just hangs up. At least most of the time. It might depend on the round-trip time whether you're lucky enough to receive a response before the connection termination. It's almost impossible to get connected to any LimeWire peers and since we don't see any headers from them, we don't receive any peer addresses from them either. -- 1000 octets = 1 ko = 1 kilooctet; 1024 octets = 1 Kio = 1 kibioctet 1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet 1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet ------------------------------ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 20, Issue 1 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
