Nabble - gtk-gnutella-devel

gtk-gnutella-devel Digest, Vol 34, Issue 3

2009-11-22T04:09:16Z

> Quoting Matthew Lye <mlye@...> from ml.softs.gtk-
> gnutella.devel:
> :So that explains the assertion failure, at least.
>
> Indeed.
>
> In r17182 I have added an assertion to check that the server's country
> code remains valid at all times. This is by no means a fix, but a
> starting
> point to see at which time things get corrupted.

The bug was reproducible with a nominally -O0 "make define && make &&
make install", but failed to survive "make clean". I hadn't ever seen
one appear in such a latent fashion, where the program could
apparently run fine for hours, I mean; only ever rapidly fatal ones.
How embarassing. I'm guessing that a typing error between segments of
object code was created?

For the record, the new assert caused the program to crash as soon as
connection attempts began.

------------------------------

Message: 5
Date: Sat, 7 Nov 2009 11:54:55 -0700
From: Lloyd Bryant <lloydbaz@...>
Subject: [gtk-gnutella-devel] Cannot build - r 17203
To: devlist <gtk-gnutella-devel@...>
Message-ID: <SNT112-W227F669A2C4D98912DB69ACEAE0@...>
Content-Type: text/plain; charset="iso-8859-1"

Just updated, and the compile failed:
---------------------------------------------------
cc -o gtk-gnutella main.o if/bridge/ui2c.o if/bridge/c2ui.o if/gnet_property.o if/gui_property.o -Lshell -lshell -Lcore -lcore -Ldht -ldht -Lui/gtk -lgtk-common -lgtkx -lgtk-common -ldht -lcore -Llib -lshared -Lsdbm -lsdbm -lshared -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lgobject-2.0 -lglib-2.0 -lxml2 -L/lib -ldbus-1 -lpthread -lrt -lgnutls -O0 -g -lz -lresolv -lm
ui/gtk/libgtk-common.a(main.o): In function `main_gui_init':
/home/lloyd/src/gtk-gnutella/src/ui/gtk/main.c:650: undefined reference to `upload_stats_common_gui_init'
ui/gtk/libgtk-common.a(main.o): In function `main_gui_shutdown':
/home/lloyd/src/gtk-gnutella/src/ui/gtk/main.c:810: undefined reference to `upload_stats_common_gui_shutdown'
collect2: ld returned 1 exit status
make[2]: *** [gtk-gnutella] Error 1
make[2]: Leaving directory `/home/lloyd/src/gtk-gnutella/src'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/lloyd/src/gtk-gnutella'
make: *** [all] Error 2
-----------------------------------------------------------
Ubuntu Linux 9.10 (Karmic Koala), GTK2, svn r17203

Lloyd B.

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 6
Date: Sat, 7 Nov 2009 19:37:59 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Cannot build - r 17203
To: gtk-gnutella-devel@...
Message-ID: <hd4ian$dqv$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Lloyd Bryant <lloydbaz@...> from ml.softs.gtk-gnutella.devel:
:Just updated, and the compile failed:

Sorry, I committed a file without realizing that it would include a symbol
pointing to something I had not yet committed, because it was not fully
tested.

Therefore, committed the code so that SVN compiles, but warning: this code
was written late and never exercised at all yet.

Raphael

------------------------------

Message: 7
Date: Sat, 21 Nov 2009 15:01:04 -0600
From: Daniel Harrison <nixscripter@...>
Subject: [gtk-gnutella-devel] The progress bar: adding a click
handler, and other things
To: gtk-gnutella-devel@...
Message-ID: <4B085510.7020402@...>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hello.

I would like to add a simple feature to gtk-gnutella: double-clicking on
the arrow in the progress bar will snap to the Sources tab, and
highlight the connection and segment which is being downloaded. I figure
it would be pretty simple: attach a button press handler to the widget
containing the window, and if it's over an arrow, map back to the file
that is in the hash. The problem is, I can't find where to attach the
handler function. Where is context->widget initialized?

Also, while I'm at it, I think I see a fairly simple way to make those
colors configurable. Is anyone else working on that?
--
Dan Harrison
"Software doesn't have bugs; sometimes, it just generates random features."

------------------------------

Message: 8
Date: Sun, 22 Nov 2009 12:08:57 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] The progress bar: adding a click
handler, and other things
To: gtk-gnutella-devel@...
Message-ID: <heb9kp$gi0$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Daniel Harrison <nixscripter@...> from ml.softs.gtk-gnutella.devel:
:I would like to add a simple feature to gtk-gnutella: double-clicking on
:the arrow in the progress bar will snap to the Sources tab, and
:highlight the connection and segment which is being downloaded. I figure
:it would be pretty simple: attach a button press handler to the widget
:containing the window, and if it's over an arrow, map back to the file
:that is in the hash. The problem is, I can't find where to attach the
:handler function. Where is context->widget initialized?

The visual progress context is in ui/gtk/visual_progress.c.

:Also, while I'm at it, I think I see a fairly simple way to make those
:colors configurable. Is anyone else working on that?

I don't think so.

Please make sure any patch changes both the GTK1 and GTK2 GUIs and does not
prevent GTKG from being compiled without a GUI.

Raphael

------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 34, Issue 3
*************************************************

gtk-gnutella-devel Digest, Vol 34, Issue 2

2009-11-05T15:48:57Z

> Quoting Matthew Lye <mlye@...> from ml.softs.gtk-
> gnutella.devel:
> :in frame 5:
> :row = 0,
> :i = 1, and
> :{struct download}key = {magic = DOWNLOAD_MAGIC, src_handle =
> :2434507541, src_handle_valid = 1,
> : error_str = "Requeued due to timeout at 10:41:53 - rescheduled for
> :10:42:13 #1\00037:43 #0", '\0' <repeats 181 times>, status =
> :GTA_DL_DONE, io_opaque = 0x0, rx = 0x0, bio = 0x0,
> : server = 0x3552c80, list_idx = DL_LIST_STOPPED, file_info =
>
> What would be interesting here is *d->server, since this is where the
> country is stored.

{struct dl_server}key->server = {magic = DL_SERVER_MAGIC, refcnt = 3,
key = 0x32f62e0, list = {0x32f64e0, 0x0,
0x335f240}, vendor = 0x4e892d0 "LimeWire/4.18.8", hostname = 0x0,
proxies = 0x35da5d0, sha1_counts = 0x97f3390, retry_after =
1257296421,
dns_lookup = 0, proxies_stamp = 0, last_connect = 0, parq_version =
{major = 0,
minor = 7305}, speed_avg = 256, attrs = 60096512, country = 19539}

So that explains the assertion failure, at least.

------------------------------

Message: 6
Date: Wed, 4 Nov 2009 17:39:50 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Odd assertion failure in iso3166.c
To: gtk-gnutella-devel@...
Message-ID: <hcse96$3pv$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
:So that explains the assertion failure, at least.

Indeed.

In r17182 I have added an assertion to check that the server's country
code remains valid at all times. This is by no means a fix, but a starting
point to see at which time things get corrupted.

Raphael

------------------------------

Message: 7
Date: Fri, 6 Nov 2009 00:28:40 +0100
From: Lars Nordlund <lars.nordlund@...>
Subject: [gtk-gnutella-devel] Build problem?
To: gtk-gnutella-devel@...
Message-ID: <20091106002840.5c76c789@laphroaig>
Content-Type: text/plain; charset=US-ASCII

Hi

When building gtk-gnutella from HEAD I get this failure:

if test -f dba; then \
/usr/pkgsrc/wip/gtk-gnutella-current/work/.tools/bin/mv dba dba~; fi
cc -o dba dba.o util.o -Lshell -lshell -Lcore -lcore -Ldht -ldht -Lui/gtk -lgtk-common -lgtkx -lgtk-common -ldht -lcore -Llib -lshared -Lsdbm -lsdbm -lshared -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lgio-2.0 -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpangoft2-1.0 -lcairo -lX11 -lpango-1.0 -lm -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lgobject-2.0 -lglib-2.0 -lintl -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lxml2 -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lgnutls -O2 -g -L. -lsdbm -L../lib -lshared -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lgobject-2.0 -lglib-2.0 -lintl
ld: cannot find -lshell
gmake[4]: *** [dba] Error 1

I created these patches to avoid the problem.

===> lars@laphroaig:/usr/pkgsrc/wip/gtk-gnutella-current %cat patches/patch-aa
$NetBSD$

--- src/Jmakefile.orig 2009-11-05 05:37:01.000000000 +0100
+++ src/Jmakefile
@@ -77,11 +77,11 @@ CFLAGS = -I.. -I. \

DPFLAGS = $(CFLAGS)
LDFLAGS = \
- -Lshell -lshell \
- -Lcore -lcore \
- -Ldht -ldht \
+ -L../shell -lshell \
+ -L../core -lcore \
+ -L../dht -ldht \
|case d_headless in undef
- -Lui/gtk -lgtk-common -lgtkx -lgtk-common \
+ -L../ui/gtk -lgtk-common -lgtkx -lgtk-common \
-case
-ldht -lcore -Llib -lshared -Lsdbm -lsdbm -lshared \
$(GTK_LDFLAGS) $(XML2_LDFLAGS) $(DBUS_LDFLAGS) $(GNUTLS_LDFLAGS) \
===> lars@laphroaig:/usr/pkgsrc/wip/gtk-gnutella-current %cat patches/patch-ab
$NetBSD$

--- src/Makefile.SH.orig 2009-11-05 23:54:27.000000000 +0100
+++ src/Makefile.SH
@@ -126,14 +126,14 @@ CFLAGS = -I.. -I. \

DPFLAGS = $(CFLAGS)
LDFLAGS = \
- -Lshell -lshell \
- -Lcore -lcore \
- -Ldht -ldht \
+ -L../shell -lshell \
+ -L../core -lcore \
+ -L../dht -ldht \
!NO!SUBS!
case "$d_headless" in
undef)
$spitshell >>Makefile <<'!NO!SUBS!'
- -Lui/gtk -lgtk-common -lgtkx -lgtk-common \
+ -L../ui/gtk -lgtk-common -lgtkx -lgtk-common \
!NO!SUBS!
;;
esac

I am not sure I need to patch both the Jmakefile and the Makefile.SH;
but I hope you get the idea about the problem I am seeing and the
changed -L path.

I do not understand why I am the only one seeing this? It seems no
fresh checkouts are buildable? This makes me think that I am doing
something wrong/strange here..

Best regards,
Lars Nordlund

------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 34, Issue 2
*************************************************

gtk-gnutella-devel Digest, Vol 34, Issue 1

2009-11-03T08:43:43Z

> #0 0x93a0ab50 in __kill ()
> #1 0x93aa5c00 in abort ()
> #2 0x001e93d8 in assertion_failure (data=<value temporarily
> unavailable, due to optimizations>) at fast_assert.c:104
> #3 0x001fbfc4 in iso3166_country_cc (code=0) at iso3166.c:423
> #4 0x00189e50 in render_sources (d=<value temporarily unavailable,
> due to optimizations>, row=0, column=1) at fileinfo.c:284
> #5 0x0018a8f0 in fi_gui_source_show (key=0x5930a00) at fileinfo.c:371
> #6 0x0015839c in fi_gui_show_info (file=0x60e7dc0) at
> downloads_common.c:1477
> #7 0x0015a730 in fi_gui_files_cursor_update () at
> downloads_common.c:1514
> #8 0x001e2460 in cq_expire (cq=0xe0e140, ev=0x0) at cq.c:482
> #9 0x001e264c in cq_clock (cq=0xe0e140, elapsed=<value temporarily
> unavailable, due to optimizations>) at cq.c:562
> #10 0x001e28cc in cq_heartbeat (cq=0xe0e140) at cq.c:613
> #11 0x001e28f0 in heartbeat_trampoline (p=<value temporarily
> unavailable, due to optimizations>) at cq.c:624
> #12 0x007226d0 in g_timeout_dispatch ()
> #13 0x00721ac4 in g_main_dispatch ()
> #14 0x00723184 in g_main_iterate ()
> #15 0x007234cc in g_main_run ()
> #16 0x00596b38 in gtk_main ()
> #17 0x0016b5bc in main_gui_run (geometry_spec=<value temporarily
> unavailable, due to optimizations>) at main.c:697
> #18 0x00003bc8 in main (argc=1, argv=0xbffff24c) at main.c:1667

ccflags='-pipe -W -Wall -Wformat=2 -Wno-shadow'

in frame 4:
d is 'unavailable due to optimizations'; row = 0, column = 1, and
{GtkCList}clist_download_sources = {container = {widget = {object =
{klass = 0xd16020, flags = 77580, ref_count = 2, object_data =
0x174eef8}, private_flags = 0, state = 0 '\0', saved_state = 0 '\0',
name = 0xd21720 "clist_download_sources", style = 0x1022200,
requisition = {width = 679, height = 27}, allocation = {x = 2, y = 2,
width = 990, height = 199}, window = 0x0,
parent = 0xd21540}, focus_child = 0x0, border_width = 0,
need_resize = 0, resize_mode = 0, reallocate_redraws = 0,
resize_widgets = 0x0}, flags = 780, row_mem_chunk = 0xd216b0,
cell_mem_chunk = 0xd21860, freeze_count = 0, internal_allocation =
{x = 0, y = 0, width = 990, height = 199}, rows = 1, row_center_offset
= 12, row_height = 15, row_list = 0x3e61d7c,
row_list_end = 0x3e61d7c, columns = 6, column_title_area = {x = 2,
y = 2, width = 986, height = 22}, title_window = 0x0, column =
0xd218a0, clist_window = 0x0, clist_window_width = 986,
clist_window_height = 173, hoffset = 0, voffset = 0, shadow_type =
GTK_SHADOW_IN, selection_mode = GTK_SELECTION_EXTENDED, selection =
0x0, selection_end = 0x0, undo_selection = 0x0,
undo_unselection = 0x0, undo_anchor = -1, button_actions =
"\003\000\000\000", drag_button = 0 '\0', click_cell = {row = -1,
column = -1}, hadjustment = 0xd214d0, vadjustment = 0xd21610,
xor_gc = 0x0, fg_gc = 0x0, bg_gc = 0x0, cursor_drag = 0x0, x_drag =
0, focus_row = 0, anchor = -1, anchor_state = GTK_STATE_SELECTED,
drag_pos = -1, htimer = 0, vtimer = 0,
sort_type = GTK_SORT_ASCENDING, compare = 0x60c310
<default_compare>, sort_column = 0}

in frame 5:
row = 0,
i = 1, and
{struct download}key = {magic = DOWNLOAD_MAGIC, src_handle =
2434507541, src_handle_valid = 1,
error_str = "Requeued due to timeout at 10:41:53 - rescheduled for
10:42:13 #1\00037:43 #0", '\0' <repeats 181 times>, status =
GTA_DL_DONE, io_opaque = 0x0, rx = 0x0, bio = 0x0,
server = 0x3552c80, list_idx = DL_LIST_STOPPED, file_info =
0x454cd00, record_index = 4294967295, file_name = 0x60c1130 "pure
ascii text]", file_size = 1218665, size = 1218665,
skip = 0, pos = 1218665, range_end = 1218665, socket = 0x0,
out_file = 0x0, overlap_size = 0, req = 0x0, buffers = 0x0, start_date
= 1257262948, last_update = 1257262975,
last_gui_update = 0, record_stamp = 1257262537, retry_after =
1257262949, head_ping_sent = 1257262912, header_sent = {tv_sec =
1257262948, tv_usec = 601382}, retries = 0,
timeout_delay = 0, served_reqs = 0, mismatches = 0, header_read_eof
= 0, data_timeouts = 0, remove_msg = 0x0, sha1 = 0x0, uri = 0x0,
last_dmesh = 1257262948, ranges = 0x0, ranges_size = 0,
sinkleft = 0, flags = 262153, cflags = 24, keep_alive = 1, push =
0, always_push = 1, got_giv = 0, unavailable = 0, cproxy = 0x0,
parq_dl = 0x0, browse = 0x0, thex = 0x0}

It would appear that iso316_country_cc os being passed a guint16 value
of 0x0, and subsequently failing the assertion "g_assert(code <
G_N_ELEMENTS(iso3166_countries))". Which would not be possible,
unless G_N_ELEMENTS(iso3166_countries) were (a) also zero, or (b)
evaluated as a [negative] signed integer rather than an unsigned
integer. G_N_ELEMENTS is a very straightforwards macro that just
divides the size of a static array by the size of array[0] to find the
number of elements. I checked the array in gdb and it seems to be
properly defined, 5180 bytes for an array of 4 byte elements, yielding
a count of 1295.

Option (b) should not be possible, given the size of the result.
Which leaves (c) a bug in glib 1.2, (d) a bug in apple's gcc (powerpc-
apple-darwin9-gcc-4.0.1), or (e) something I want to learn.

This crash has occurred once before in the past week; I had not
encountered it before then. However, this may not be relevant to
recent commits as it seems to be dependent on file data.

regards,
Matt

------------------------------

------------------------------------------------------------------------------
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 34, Issue 1
*************************************************

gtk-gnutella-devel Digest, Vol 33, Issue 1

2009-10-31T13:55:33Z

gtk-gnutella-devel Digest, Vol 33, Issue 1

2009-10-29T04:28:44Z

gtk-gnutella-devel Digest, Vol 32, Issue 3

2009-09-25T08:27:22Z

> cc -o dbu dbu.o util.o -O2 -g -L. -lsdbm -L../lib -lshared -lglib
> collect2: ld terminated with signal 6 [Abort trap]
> Undefined symbols
> "_libiconv_open", referenced from:
> _utf8_cd_get in libshared.a(utf8.o)
> _locale_init in libshared.a(utf8.o)
> _locale_init in libshared.a(utf8.o)
> _locale_init in libshared.a(utf8.o)
> _locale_init in libshared.a(utf8.o)
> _locale_init in libshared.a(utf8.o)
> "_libiconv", referenced from:
> _complete_iconv in libshared.a(utf8.o)
> _complete_iconv in libshared.a(utf8.o)
> _complete_iconv in libshared.a(utf8.o)
> terminate called after throwing an instance of 'char const*'
> terminate called recursively
> make[4]: *** [dbu] Error 1
> make[3]: *** [subdirs] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [subdirs] Error 1
> make: *** [all] Error 2

This failure is identical each time, except that the undefined symbols
will be "_iconv" "_inconv_open" when I try to link to a static version
of libiconv. The symbol *is* defined in the relevant library in all
cases.

I believe that this problem has its roots in the Darwin OS's
implementation of /usr/lib/libiconv.* and/or /usr/include/iconv.h
being incompatible with the newer GNU versions, and that it involves
macros and C++; there are lots of message board posts reporting iconv
errors when people try to port projects to Darwin. I know that I've
encountered problems with iconv before and that they were solved.
What I don't recall is exactly who managed to solve it or how it was
done. I've been unable to find a solid discussion or solution posted
anywhere; it's possible that the situation makes a lot more sense to
someone who understands C++, which I do not.

Things I have tried:
- eliminating I_ICONV guard. (I_ICONV is defined, anyways.)
- specifying full pathnames of all libraries
- specifying explicit pathname of iconv.h
- linking specifically to static version of libiconv, both native and
GNU.
- changing the name of the GNU iconv library and header

Any ideas or suggestions?

------------------------------

Message: 6
Date: Thu, 24 Sep 2009 18:20:09 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] iconv avec ennui.
To: gtk-gnutella-devel@...
Message-ID: <h9gd8p$l4f$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
:Since the recent changes in ./src/sdbm, I have been encountering a
:compile-time error originating with ./src/lib/utf8.o 's links to the
:iconv library. My system is a ppc7450 iMac running OS X 10.5.8, which
:has Darwin 9.8.0.
:
:> cc -o dbu dbu.o util.o -O2 -g -L. -lsdbm -L../lib -lshared -lglib
:> collect2: ld terminated with signal 6 [Abort trap]
:> Undefined symbols
:> "_libiconv_open", referenced from:
:> _utf8_cd_get in libshared.a(utf8.o)

The utf8.o file should not be loaded when linking dbu, since none of the
UTF-8 routines are used by dbu nor by sdbm...

:I believe that this problem has its roots in the Darwin OS's
:implementation of /usr/lib/libiconv.* and/or /usr/include/iconv.h
:being incompatible with the newer GNU versions, and that it involves
:macros and C++; there are lots of message board posts reporting iconv
:errors when people try to port projects to Darwin.

Again, we're talking about a library here, and the normal linker behaviour
should be to not load a file from the library unless one of the symbols
defined by the file is needed.

I've checked locally the symbols in my linked dbu, and I'm astonished
to see that symbols like cq_cancel() are defined.

:Any ideas or suggestions?

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.

Fixing this will probably require splitting the "shared" library in more
than one so that we can only the files for the required symbols, which are:

assertion_failure
common_stats
compat_pread
compat_pwrite
fd_close
file_open
h_strconcat
h_strdup
halloc_init
hash_list_free
hash_list_iter_previous
hash_list_iter_release
hash_list_iterator_tail
hash_list_moveto_head
hash_list_new
hash_list_prepend
hash_list_tail
hfree
hrealloc
vmm_alloc
vmm_free
vmm_init
walloc
walloc0
wfree
wrealloc

>From that list, I can almost see where the problem lies: the fact that we
need h_strdup() means that the whole misc.o file needs to be loaded, which
in turn causes many other library files to be required given the diverse
routines defined there.

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.

Raphael

------------------------------

Message: 7
Date: Fri, 25 Sep 2009 15:27:05 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] iconv avec ennui.
To: gtk-gnutella-devel@...
Message-ID: <h9ing9$roa$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
:Since the recent changes in ./src/sdbm, I have been encountering a
:compile-time error originating with ./src/lib/utf8.o 's links to the
:iconv library. My system is a ppc7450 iMac running OS X 10.5.8, which
:has Darwin 9.8.0.

Let me know if things work out with r16991.
I no longer see any utf8 symbols in the linked "dbu" here.

Also I've fixed the linking line to work with glib 2.x.

Raphael

------------------------------

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 32, Issue 3
*************************************************

gtk-gnutella-devel Digest, Vol 32, Issue 2

2009-09-17T10:14:52Z

> Quoting Matthew Lye <mlye@...> from ml.softs.gtk-
> gnutella.devel:
> :More like this? It wasn't as difficult as I thought, once I got used
> :to the functions.
>
> Yes, this is a correct patch. Thank you.
>
> I've committed it in SVN as r16961 with slight style corrections.
>
> Also I've addeed a provision to make sure the address of such
> challenging
> hosts is removed from the fresh/valid host caches, to avoid further
> propagation of that address, but this is incomplete because I did not
> parse X-Node or X-Listen-IP or X-My-Address to know the proper port...
>
> I've added it as a TODO locally, but if you want to contribute the
> necessary patch... :-) Look at feed_host_cache_from_string() for
> inspiration.
> We can probably extract the parsing code from there to reuse it.

Sorry, I should have thought of this before I wrote the patch:
although the situation with the patch is *better* in terms of the
amount of Foxy clogging, it's a half-step back from the "ban.c"
solution.

GTKG still appears to get IP suggestions that lead to Foxy servents,
presumably from third party servents.

The problem is that when GTKG eventually tries one of these IPs, it
results in a 503 response from the Foxy servent:
> 09-09-07 23:25:44 (MESSAGE): ----Got outgoing handshaking headers
> from TH.FOXY.NO.DE:
> GNUTELLA/0.6 503 No QRP
> User-Agent: Foxy 1.9.9.0
> Remote-IP: GTK.GNU.TEL.LA:PORT
> X-Try-Hubs: 1ST.FOXY.NO.DE:PORT 2009-09-08T11:25Z,
> 2ND.FOXY.NO.DE:PORT 2009-09-08T11:25Z, 3RD.FOXY.NO.DE:PORT...

As you can see, the 503 header does not include an "X-Auth-Challenge"
line; we've already failed the authentication by not establishing it
ourselves.

This means that Foxy is still periodically stuffing the host cache in
a cascading manner.

Matt

------------------------------

Message: 2
Date: Tue, 8 Sep 2009 05:38:43 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Foxy 1.9.9.0 in hostcache?
To: gtk-gnutella-devel@...
Message-ID: <h84ql3$lb1$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
:GTKG still appears to get IP suggestions that lead to Foxy servents,
:presumably from third party servents.
:
:The problem is that when GTKG eventually tries one of these IPs, it
:results in a 503 response from the Foxy servent:
:> 09-09-07 23:25:44 (MESSAGE): ----Got outgoing handshaking headers
:> from TH.FOXY.NO.DE:
:> GNUTELLA/0.6 503 No QRP
:> User-Agent: Foxy 1.9.9.0
:> Remote-IP: GTK.GNU.TEL.LA:PORT
:> X-Try-Hubs: 1ST.FOXY.NO.DE:PORT 2009-09-08T11:25Z,
:> 2ND.FOXY.NO.DE:PORT 2009-09-08T11:25Z, 3RD.FOXY.NO.DE:PORT...
:
:As you can see, the 503 header does not include an "X-Auth-Challenge"
:line; we've already failed the authentication by not establishing it
:ourselves.

X-Try-Hubs is another sure sign of a foreign network. Gnutella servents
never emit this header, which belongs to the Mike Protocol used by Shareaza,
for instance.

Hence a 503 with that header means that we can surely hcache_purge()
that IP:port, along with all the listed IPs on X-Try-Hubs...

Raphael

------------------------------

Message: 3
Date: Wed, 9 Sep 2009 16:50:47 +0300 (EEST)
From: Meelis Roos <mroos@...>
Subject: [gtk-gnutella-devel] crash in yesterdays SVN
To: gtk-gnutella-devel@...
Message-ID: <alpine.SOC.1.00.0909091640510.25332@...>
Content-Type: TEXT/PLAIN; charset=US-ASCII

Running rev 16961 since yesterday as ultranode, and got this crash
today. DHT is enabled by hand. Previous uptime was about 56 days with
DHT of that timeframe.

Core was generated by `/home/mroos/gg/bin/gtk-gnutella'.
Program terminated with signal 11, Segmentation fault.
#0 0x081639a6 in lk_handle_reply (obj=0xbbfc2348, kn=0xbd51c2c0, function=KDA_MSG_FIND_NODE_RESPONSE, payload=0xb714f03d "\004\215?\205\024LIME", len=666, hop=15)
at lookup.c:2430
2430 nl->flags |= NL_F_COMPLETED; /* For lookup_expired() to check */
(gdb) p nl
$1 = <value optimized out>
(gdb) bt
#0 0x081639a6 in lk_handle_reply (obj=0xbbfc2348, kn=0xbd51c2c0, function=KDA_MSG_FIND_NODE_RESPONSE, payload=0xb714f03d "\004\215?\205\024LIME", len=666, hop=15)
at lookup.c:2430
#1 0x08166458 in revent_rpc_cb (type=DHT_RPC_REPLY, kn=0xbd51c2c0, unused_n=0xbfa95aa0, function=KDA_MSG_FIND_NODE_RESPONSE, payload=0xb714f03d "\004\215?\205\024LIME", len=666,
arg=0xbe05c708) at revent.c:427
#2 0x08170ec0 in dht_rpc_answer (muid=0xb714f000, kn=0xbeb72040, n=0xbfa95aa0, function=KDA_MSG_FIND_NODE_RESPONSE, payload=0xb714f03d, len=666) at rpc.c:410
#3 0x08155528 in k_handle_rpc_reply (kn=0xbeb72040, n=0xbfa95aa0, header=0xb714f000, extlen=0 '\0', payload=0xb714f03d, len=666) at kmsg.c:1503
#4 0x08156c2b in kmsg_received (data=0xb714f000, len=727, addr={net = 4, addr = {ipv6 = "?W??\003??\003??\003?", ipv4 = 1975932833}}, port=33021, n=0xbfa95aa0) at kmsg.c:198
#5 0x080e2940 in node_udp_process (s=0xb7155120) at nodes.c:7050
#6 0x08139cdc in udp_received (s=0xb7155120, truncated=0) at udp.c:277
#7 0x0812b7be in socket_udp_event (data=0xb7155120, unused_source=9, cond=<value optimized out>) at sockets.c:2413
#8 0x0822e482 in dispatch_poll (unused_source=0x83c1200, unused_cond=G_IO_IN, udata=0x83a5520) at inputevt.c:714
#9 0xb78bccbf in g_io_unix_dispatch (source=0x83c1248, callback=0x822e312 <dispatch_poll>, user_data=0x83a5520) at giounix.c:162
#10 0xb7893771 in IA__g_main_context_dispatch (context=0x83c1380) at gmain.c:2045
#11 0xb78967e6 in g_main_context_iterate (context=0x83c1380, block=1, dispatch=1, self=0x83c3eb8) at gmain.c:2677
#12 0xb7896ba7 in IA__g_main_loop_run (loop=0x853fd78) at gmain.c:2881
#13 0xb7d2b281 in IA__gtk_main () at gtkmain.c:1003
#14 0x0818072e in main_gui_run (geometry_spec=0x0) at main.c:695
#15 0x08056531 in main (argc=1, argv=0xbfaebf54) at main.c:1616

--
Meelis Roos (mroos@...)

------------------------------

Message: 4
Date: Wed, 9 Sep 2009 18:02:54 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] crash in yesterdays SVN
To: gtk-gnutella-devel@...
Message-ID: <h88qke$euo$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Meelis Roos <mroos@...> from ml.softs.gtk-gnutella.devel:
:Running rev 16961 since yesterday as ultranode, and got this crash
:today. DHT is enabled by hand. Previous uptime was about 56 days with
:DHT of that timeframe.

There has been no changes to the DHT code in recent versions, so the
problem you're experiencing is due to an existing bug. It's a rather
critical bug, but hopefully it does not manifest too often (never had it
here).

Fixed in r16963. Thanks for reporting it.

Raphael

------------------------------

Message: 5
Date: Wed, 9 Sep 2009 20:05:14 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Foxy 1.9.9.0 in hostcache?
To: gtk-gnutella-devel@...
Message-ID: <h891pq$t2$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Raphael_Manfredi@... (Raphael Manfredi):
:I've added it as a TODO locally, but if you want to contribute the
:necessary patch... :-) Look at feed_host_cache_from_string() for inspiration.
:We can probably extract the parsing code from there to reuse it.

I've finally fixed the missing part in r16965.

Raphael

------------------------------

Message: 6
Date: Thu, 17 Sep 2009 14:23:19 +0200
From: Hauke Hachmann <haxe@...>
Subject: [gtk-gnutella-devel] Unable to connect
To: gtk-gnutella-devel@...
Message-ID: <200909171423.20118.haxe@...>
Content-Type: Text/Plain; charset="us-ascii"

Hi folks,

this may or may not have to do with the recent changes to avoid useless
connection attempts no non-gnutella clients. Since some days, I cannot
connect to any ultrapeer. My gtk-gnutella leaf client is completely
isolated and useless. Maybe there is something wrong with the new
rejection logic?

bye,

Hauke Hachmann

------------------------------

Message: 7
Date: Thu, 17 Sep 2009 14:23:19 +0200
From: Hauke Hachmann <haxe@...>
Subject: [gtk-gnutella-devel] Unable to connect
To: gtk-gnutella-devel@...
Message-ID: <200909171423.20118.haxe@...>
Content-Type: Text/Plain; charset="us-ascii"

Hi folks,

this may or may not have to do with the recent changes to avoid useless
connection attempts no non-gnutella clients. Since some days, I cannot
connect to any ultrapeer. My gtk-gnutella leaf client is completely
isolated and useless. Maybe there is something wrong with the new
rejection logic?

bye,

Hauke Hachmann

------------------------------

Message: 8
Date: Thu, 17 Sep 2009 17:23:48 +0200
From: Hauke Hachmann <haxe@...>
Subject: Re: [gtk-gnutella-devel] Unable to connect
To: gtk-gnutella-devel@...
Message-ID: <200909171723.48185.haxe@...>
Content-Type: Text/Plain; charset="iso-8859-1"

On Thursday 17 September 2009, Matthew Lye wrote:
> Which gtkg version are you using?

Ah, sorry, I forgot to mention. At the moment, I am using r16974 (which
is the newest from SVN), but I think that my problems were already
present at least with r16970, probably even earlier. OTOH, I know that
it still worked one week ago, so the error cannot be very old.

Bye,

Hauke

------------------------------

Message: 9
Date: Thu, 17 Sep 2009 17:14:29 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Unable to connect
To: gtk-gnutella-devel@...
Message-ID: <h8tqpl$roi$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Hauke Hachmann <haxe@...> from ml.softs.gtk-gnutella.devel:
:Ah, sorry, I forgot to mention. At the moment, I am using r16974 (which
:is the newest from SVN), but I think that my problems were already
:present at least with r16970, probably even earlier. OTOH, I know that
:it still worked one week ago, so the error cannot be very old.

Is gtk-gnutella at least attempting to connect or is it just sitting there,
idle? In that case, you need to check the size of your hostcaches (go
to the "Hostcache" tab) and that you did not accidentally hit the "disconnect"
icon (at the bottom left) which prevents all Gnutella connections.

Raphael

------------------------------

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 32, Issue 2
*************************************************

gtk-gnutella-devel Digest, Vol 32, Issue 1

2009-09-07T12:44:29Z

> Matthew Lye wrote:
>> I'm noticing an extraordinary number of outgoing attempts to connect
>> to Foxy 1.9.9.0 clients in Taiwan and Hong Kong as GTKG starts up,
>> here. Could the [swarms of] Foxy clients which are [always] failing
>> to connect as incoming connections nonetheless be ending up in the
>> GTKG hostcache?
>
> I've looked at some of the handshakes. Apparently, they always hang up
> after the first handshake response which seems to indicate they don't
> like some of the parameters. Maybe they just hang up due to the
> missing "X-Auth-Challenge" in the response. These handshakes look more
> or less like normal Gnutella handshakes. According to my information
> though Foxy isn't based on Gnutella but G2, the handshake doesn't
> indicate
> this. I've seen a search result from Foxy exactly once so far. So Foxy
> doesn't really seem to be using Gnutella.

I looked into this, and yes, they do hang up due to GTKG's failure to
answer the authentication challenge. This is correct behavior [1].

"X-Auth-Challenge" is a header originating from the GnucDNA API, which
supports both Gnutella and G2 networks. The authorization challenge
is not intended to be used in open P2P networks, it makes sense only
for use by closed (private) GWebCache and/or Hub based networks. It
is a bit of a mystery as to why Foxy clients would be attempting to
contact us in the first place, but it is very definitely an error for
GTKG to be adding Foxy servent nodes to the host cache.

When GTKG attempts to accept an incoming Foxy connection, it fails to
answer the authentication challenge (one would need the correct shared
code number) and is dropped. In this circumstance, the Foxy servent's
IP is added to the host cache via the Listen-Ip header, even though
the connection with the Foxy servent fails. What is worse, however,
is when GTKG later (or in another session) attempts to connect to the
listed Foxy servent. Since no authentication challenge is included, a
503 error is returned, along with an X-Try-Ultrapeer message listing
several Foxy ultrapeers. These will be added to the host cache, and
tried in turn, with exponential effect.

Oddly, attempting to connect to a Foxy servent inspires a burst of
incoming handshake attempts from other Foxy servents. If I had to
guess, I would say that the Foxy developers simply took an off-the-
shelf open source servent and modified it to add an authentication
stage. There seems to be no awareness in the controlling logic that
other Foxy servents would be inherently disinterested in connecting to
any non-Foxy servent. Perhaps something tricker is going on, and Foxy
servents are supposed to be taking advantage of the wider Gnutella
network for searches while remaining opaque, and the implementation of
this has been suspended or badly bungled, I don't know. However, I do
know that Foxy node connections will always fail, with good reason.

The main problem presented by Foxy (from my observation) is the linger
time of failed Foxy connections. This slows down the network-
connecting process considerably. For this reason, Foxy connections
should be recognized and refused, as they are inherently undesirable
(on either side).

The elegant thing to do would be to recognize that a handshake
including a X-Auth-Challenge line will not be completed, and terminate
all such connections. Likewise, it would seem prudent to reject the
caching of host data originating from such servents (if not all
servents that fail to complete handshakes, period). However, this
may conflict with prior control logic decisions, and is beyond my
ability in any case. I am testing, and would recommend, the following:

Step 1: Hardcode Foxy as a banned vendor in "vendors.c"
Step 2: Move the call of 'extract_header_pongs(n, head)' from line
5126 of "core/nodes.c" so that it occurs directly *after* the vendor
specific banning step (i.e, at about what is currently line 5353).

This doesn't manage to completely eliminate the incoming Foxy
connection attempts, but it reduces their numbers, greatly speeds
their disposal, and eliminates the hcache problem.

- Matt

References:
[1] http://www.gnucleus.com/GnucDNA/docs/authentication.html

------------------------------

Message: 3
Date: Mon, 7 Sep 2009 07:15:13 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Foxy 1.9.9.0 in hostcache?
To: gtk-gnutella-devel@...
Message-ID: <h82bu1$999$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
I am testing, and would recommend, the following:
:
:Step 1: Hardcode Foxy as a banned vendor in "vendors.c"
:Step 2: Move the call of 'extract_header_pongs(n, head)' from line
:5126 of "core/nodes.c" so that it occurs directly *after* the vendor
:specific banning step (i.e, at about what is currently line 5353).
:
:This doesn't manage to completely eliminate the incoming Foxy
:connection attempts, but it reduces their numbers, greatly speeds
:their disposal, and eliminates the hcache problem.

Godd analysis of the problem, and probably correct remediation attempt.
Unfortunately, I'm quite busy on other stuff right now and cannot devote
any time to GTKG for the time being. I shall probably remain busy until
the end of September.

If you can come up with a patch, it will greatly speed-up things. :-)

Thanks,
Raphael

------------------------------

Message: 4
Date: Mon, 7 Sep 2009 10:20:47 -0400
From: Matthew Lye <mlye@...>
Subject: Re: [gtk-gnutella-devel] SPAM-LOW: Re: Foxy 1.9.9.0 in
hostcache?
To: gtk-gnutella-devel@...
Message-ID: <F0A72950-936E-4CF3-972A-91EE26A378D6@...>
Content-Type: text/plain; charset="us-ascii"

On 7-Sep-09, at 3:15 AM, Raphael Manfredi wrote:

> Quoting Matthew Lye <mlye@...> from ml.softs.gtk-
> gnutella.devel:
>> I am testing, and would recommend, the following...
> If you can come up with a patch, it will greatly speed-up things. :-)

Okay, sure. I'd normally be reluctant to offer a patch, but the
changes involved are really pretty simple.
For purposes of archive, note that I mistakenly specified "vendors.c"
earlier in this thread when I of course meant "ban.c"

Application should be "patch -p0 Foxy.patch" from the root svn
directory.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Foxy.patch
Type: application/octet-stream
Size: 1265 bytes
Desc: not available
-------------- next part --------------

------------------------------

Message: 5
Date: Mon, 7 Sep 2009 15:44:47 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] SPAM-LOW: Re: Foxy 1.9.9.0 in
hostcache?
To: gtk-gnutella-devel@...
Message-ID: <h839pf$arc$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
:Okay, sure. I'd normally be reluctant to offer a patch, but the
:changes involved are really pretty simple.
:For purposes of archive, note that I mistakenly specified "vendors.c"
:earlier in this thread when I of course meant "ban.c"

Your patch ties the ban logic to the Foxy servent name. This is probably not
what we want: I'd prefer something that looks for the authentication header
in the handshake, regardless of the servent name.

In the future, Foxy may remove the header and become fully inter-operable,
so hardcoding their name is dangerous. Second, another vendor may choose to
do the same thing with another name.

Raphael

------------------------------

Message: 6
Date: Mon, 7 Sep 2009 13:01:56 -0400
From: Matthew Lye <mlye@...>
Subject: Re: [gtk-gnutella-devel] SPAM-LOW: Re: Foxy 1.9.9.0 in
hostcache?
To: gtk-gnutella-devel@...
Message-ID: <709B6B26-6446-4062-A501-8772037EECE7@...>
Content-Type: text/plain; charset="us-ascii"

On 7-Sep-09, at 11:44 AM, Raphael Manfredi wrote:
> Your patch ties the ban logic to the Foxy servent name. This is
> probably not
> what we want: I'd prefer something that looks for the authentication
> header
> in the handshake, regardless of the servent name.

More like this? It wasn't as difficult as I thought, once I got used
to the functions.
I've been thinking more, and in my opinion this is still kinda kludgy,
because the simplest behavior for a good open/closed dual servent
would probably be to try to authenticate first, and then act as a
portal servent upon failure. And there might well be legitimate
reasons to forms sub-networks like that, especially with GWebcache or
hub organized servents. However, here's the patch for your
consideration; its better than nothing in the current network
environment.

patch -p0 <Foxy.patch

- Matt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Foxy.patch
Type: application/octet-stream
Size: 1469 bytes
Desc: not available
-------------- next part --------------

------------------------------

Message: 7
Date: Mon, 7 Sep 2009 19:44:01 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Foxy 1.9.9.0 in hostcache?
To: gtk-gnutella-devel@...
Message-ID: <h83nq1$8g0$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
:More like this? It wasn't as difficult as I thought, once I got used
:to the functions.

Yes, this is a correct patch. Thank you.

I've committed it in SVN as r16961 with slight style corrections.

Also I've addeed a provision to make sure the address of such challenging
hosts is removed from the fresh/valid host caches, to avoid further
propagation of that address, but this is incomplete because I did not
parse X-Node or X-Listen-IP or X-My-Address to know the proper port...

I've added it as a TODO locally, but if you want to contribute the
necessary patch... :-) Look at feed_host_cache_from_string() for inspiration.
We can probably extract the parsing code from there to reuse it.

Raphael

------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 32, Issue 1
*************************************************

gtk-gnutella-devel Digest, Vol 31, Issue 1

2009-07-15T23:17:28Z

gtk-gnutella-devel Digest, Vol 30, Issue 2

2009-06-13T16:56:00Z

gtk-gnutella-devel Digest, Vol 30, Issue 1

2009-06-01T01:30:51Z

gtk-gnutella-devel Digest, Vol 29, Issue 5

2009-05-30T03:25:17Z

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. misc pedantic in zalloc.c (Matthew Lye)
2. Re: misc pedantic in zalloc.c (Christian Biere)
3. Re: Crash at startup (Hauke Hachmann)
4. Re: Crash at startup (Hauke Hachmann)

----------------------------------------------------------------------

Message: 1
Date: Fri, 29 May 2009 22:59:00 -0400
From: Matthew Lye <mlye@...>
Subject: [gtk-gnutella-devel] misc pedantic in zalloc.c
To: gtk-gnutella-devel@...
Message-ID: <51E9F483-1A47-4C95-84D7-A33268D62740@...>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Pedantic warnings on size_t not properly cast to unsigned for use by
"%u":

line 563, the last 'rounded'
line 570, the last 'rounded'
line 1797, 'used' in second-last argument.

Not sure if size_t is ever not unsigned long, but they typed it, so.

------------------------------

Message: 2
Date: Sat, 30 May 2009 10:35:45 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] misc pedantic in zalloc.c
To: gtk-gnutella-devel@...
Message-ID: <20090530083545.GA14775@...>
Content-Type: text/plain; charset=utf-8

Matthew Lye wrote:
> Pedantic warnings on size_t not properly cast to unsigned for use by
> "%u":
>
> line 563, the last 'rounded'
> line 570, the last 'rounded'
> line 1797, 'used' in second-last argument.
>
> Not sure if size_t is ever not unsigned long, but they typed it, so.

Actually, these aren't pedantic warnings, so they should always be
reported, especially as these aren't visible and easy to miss on
32-bit machines. So it's quite appreciated you reported them. Thanks.

--
Christian

------------------------------

Message: 3
Date: Sat, 30 May 2009 12:07:03 +0200
From: Hauke Hachmann <haxe@...>
Subject: Re: [gtk-gnutella-devel] Crash at startup
To: gtk-gnutella-devel@...
Message-ID: <200905301207.04067.haxe@...>
Content-Type: Text/Plain; charset="iso-8859-1"

On Saturday 30 May 2009, Raphael Manfredi wrote:
> :Could you provide a stack trace and a cat of /proc/self/maps?
> :Maybe any of it gives some obvious glue.
>
> And please, could you turn on vmm_debug to 1 and show the last "VMM"
> messages before the crash?

OK, I sent that. But my mail awaits moderator approval, because it is
too long. Is anyone in charge of that?

h

------------------------------

Message: 4
Date: Sat, 30 May 2009 00:52:27 +0200
From: Hauke Hachmann <haxe@...>
Subject: Re: [gtk-gnutella-devel] Crash at startup
To: gtk-gnutella-devel@...
Message-ID: <200905300052.27378.haxe@...>
Content-Type: Text/Plain; charset="iso-8859-1"

On Saturday 30 May 2009, Raphael Manfredi wrote:
> :Could you provide a stack trace and a cat of /proc/self/maps?
> :Maybe any of it gives some obvious glue.
>
> And please, could you turn on vmm_debug to 1 and show the last "VMM"
> messages before the crash?

OK, here it comes.

/proc/self/maps
=======================
00400000-0040d000 r-xp 00000000 fd:01 1758245 /bin/cat
0060d000-0060e000 rw-p 0000d000 fd:01 1758245 /bin/cat
01f73000-01f94000 rw-p 01f73000 00:00 0 [heap]
7fe69340a000-7fe693674000 r--p 00000000 fd:01 1425682
/usr/lib/locale/locale-archive
7fe693674000-7fe6937bd000 r-xp 00000000 fd:01 1507516
/lib/libc-2.9.so
7fe6937bd000-7fe6939bd000 ---p 00149000 fd:01 1507516
/lib/libc-2.9.so
7fe6939bd000-7fe6939c1000 r--p 00149000 fd:01 1507516
/lib/libc-2.9.so
7fe6939c1000-7fe6939c2000 rw-p 0014d000 fd:01 1507516
/lib/libc-2.9.so
7fe6939c2000-7fe6939c7000 rw-p 7fe6939c2000 00:00 0
7fe6939c7000-7fe6939e4000 r-xp 00000000 fd:01 1507511
/lib/ld-2.9.so
7fe693bc1000-7fe693bc3000 rw-p 7fe693bc1000 00:00 0
7fe693be0000-7fe693be3000 rw-p 7fe693be0000 00:00 0
7fe693be3000-7fe693be4000 r--p 0001c000 fd:01 1507511
/lib/ld-2.9.so
7fe693be4000-7fe693be5000 rw-p 0001d000 fd:01 1507511
/lib/ld-2.9.so
7fff9bbd0000-7fff9bbe5000 rw-p 7ffffffea000 00:00 0
[stack]
7fff9bbff000-7fff9bc00000 r-xp 7fff9bbff000 00:00 0
[vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]

Crash messages with VMM debug
=======================
09-05-30 00:31:22 (MESSAGE): gtk-gnutella/0.96.7u-16818 (2009-03-30;
GTK2; Linux x86_64)
09-05-30 00:31:23 (MESSAGE): VMM using 131840 bytes for the page cache
09-05-30 00:31:23 (MESSAGE): VMM kernel grows virtual memory by
decreasing addresses
09-05-30 00:31:23 (MESSAGE): VMM stack grows by decreasing addresses
09-05-30 00:31:23 (MESSAGE): VMM initial break at 0x166d000
09-05-30 00:31:23 (MESSAGE): VMM stack bottom at 0x7fff02b434ac
09-05-30 00:31:23 (MESSAGE): VMM stack has at most 8519688KiB to grow
09-05-30 00:31:24 (WARNING): VMM kernel did not follow hint
0xffffffffff5fe000 for 8KiB region, picked 0x7ffcf1e9f000
09-05-30 00:31:24 (WARNING): pmap already contains the new region
[0x7ffcf1e9f000, 0x7ffcf1ea0fff]
09-05-30 00:31:24 (MESSAGE): VMM current kernel pmap (253 regions):
09-05-30 00:31:24 (MESSAGE): VMM [0x400000, 0x7a5fff] 3736KiB (foreign) +
2044KiB hole
09-05-30 00:31:24 (MESSAGE): VMM [0x9a5000, 0x9affff] 44KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x9b0000, 0xa37fff] 544KiB + 12368KiB
hole
09-05-30 00:31:24 (MESSAGE): VMM [0x164c000, 0x256cfff] 15492KiB +
137426060784KiB hole
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcef6e9000, 0x7ffcf020efff] 11416KiB
+ 29248KiB hole
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf1e9f000, 0x7ffcf1ea9fff] 44KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf1eaa000, 0x7ffcf1eadfff] 16KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf1eae000, 0x7ffcf20adfff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf20ae000, 0x7ffcf20aefff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf20af000, 0x7ffcf2130fff] 520KiB +
4KiB hole
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2132000, 0x7ffcf2173fff] 264KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2174000, 0x7ffcf2175fff] 8KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2176000, 0x7ffcf2374fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2375000, 0x7ffcf2375fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2376000, 0x7ffcf2389fff] 80KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf238a000, 0x7ffcf2589fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf258a000, 0x7ffcf258cfff] 12KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf258d000, 0x7ffcf25affff] 140KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf25b0000, 0x7ffcf27affff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf27b0000, 0x7ffcf27b2fff] 12KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf27b3000, 0x7ffcf27c5fff] 76KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf27c6000, 0x7ffcf29c5fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf29c6000, 0x7ffcf29c6fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf29c7000, 0x7ffcf29d3fff] 52KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf29d4000, 0x7ffcf29e4fff] 68KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf29e5000, 0x7ffcf29e6fff] 8KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf29e7000, 0x7ffcf2be5fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2be6000, 0x7ffcf2be6fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2be7000, 0x7ffcf2beffff] 36KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2bf0000, 0x7ffcf2bf7fff] 32KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2bf8000, 0x7ffcf2c71fff] 488KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2c72000, 0x7ffcf2c77fff] 24KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2c78000, 0x7ffcf2e77fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2e78000, 0x7ffcf2e78fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2e79000, 0x7ffcf2e7afff] 8KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf2e7b000, 0x7ffcf3079fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf307a000, 0x7ffcf307afff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf307b000, 0x7ffcf307bfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf307c000, 0x7ffcf32e5fff] 2472KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf32e6000, 0x7ffcf32f0fff] 44KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf32f1000, 0x7ffcf34effff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf34f0000, 0x7ffcf34f0fff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf34f1000, 0x7ffcf34f1fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf34f2000, 0x7ffcf34fbfff] 40KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf34fc000, 0x7ffcf36fafff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf36fb000, 0x7ffcf36fbfff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf36fc000, 0x7ffcf36fcfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf36fd000, 0x7ffcf3711fff] 84KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3712000, 0x7ffcf3910fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3911000, 0x7ffcf3911fff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3912000, 0x7ffcf3912fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3913000, 0x7ffcf3914fff] 8KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3915000, 0x7ffcf391bfff] 28KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf391c000, 0x7ffcf3b1afff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3b1b000, 0x7ffcf3b1bfff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3b1c000, 0x7ffcf3b1cfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3b1d000, 0x7ffcf3b21fff] 20KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3b22000, 0x7ffcf3d20fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3d21000, 0x7ffcf3d21fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3d22000, 0x7ffcf3d23fff] 8KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3d24000, 0x7ffcf3f22fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3f23000, 0x7ffcf3f23fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3f24000, 0x7ffcf3f26fff] 12KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf3f27000, 0x7ffcf4125fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf4126000, 0x7ffcf4126fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf4127000, 0x7ffcf4199fff] 460KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf419a000, 0x7ffcf4398fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf4399000, 0x7ffcf439cfff] 16KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf439d000, 0x7ffcf43acfff] 64KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf43ad000, 0x7ffcf45abfff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf45ac000, 0x7ffcf45acfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf45ad000, 0x7ffcf45d3fff] 156KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf45d4000, 0x7ffcf47d3fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf47d4000, 0x7ffcf47d5fff] 8KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf47d6000, 0x7ffcf47f0fff] 108KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf47f1000, 0x7ffcf49f0fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf49f1000, 0x7ffcf49f1fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf49f2000, 0x7ffcf49f8fff] 28KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf49f9000, 0x7ffcf4bf8fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf4bf9000, 0x7ffcf4bf9fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf4bfa000, 0x7ffcf4bfcfff] 12KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf4bfd000, 0x7ffcf4dfbfff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf4dfc000, 0x7ffcf4dfcfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf4dfd000, 0x7ffcf4e21fff] 148KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf4e22000, 0x7ffcf5020fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5021000, 0x7ffcf5021fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5022000, 0x7ffcf5037fff] 88KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5038000, 0x7ffcf5236fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5237000, 0x7ffcf5237fff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5238000, 0x7ffcf5238fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5239000, 0x7ffcf523cfff] 16KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf523d000, 0x7ffcf5254fff] 96KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5255000, 0x7ffcf5454fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5455000, 0x7ffcf5455fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5456000, 0x7ffcf5456fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5457000, 0x7ffcf545ffff] 36KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5460000, 0x7ffcf565ffff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5660000, 0x7ffcf5660fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5661000, 0x7ffcf56e6fff] 536KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf56e7000, 0x7ffcf58e6fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf58e7000, 0x7ffcf58eafff] 16KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf58eb000, 0x7ffcf592dfff] 268KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf592e000, 0x7ffcf5b2cfff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5b2d000, 0x7ffcf5b2ffff] 12KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5b30000, 0x7ffcf5b49fff] 104KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5b4a000, 0x7ffcf5d48fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5d49000, 0x7ffcf5d4afff] 8KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5d4b000, 0x7ffcf5d4bfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5d4c000, 0x7ffcf5d7afff] 188KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5d7b000, 0x7ffcf5f79fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5f7a000, 0x7ffcf5f7afff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5f7b000, 0x7ffcf5f7cfff] 8KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf5f7d000, 0x7ffcf617cfff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf617d000, 0x7ffcf617dfff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf617e000, 0x7ffcf617efff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf617f000, 0x7ffcf6187fff] 36KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6188000, 0x7ffcf6387fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6388000, 0x7ffcf6388fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6389000, 0x7ffcf6390fff] 32KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6391000, 0x7ffcf658ffff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6590000, 0x7ffcf6590fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6591000, 0x7ffcf6599fff] 36KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf659a000, 0x7ffcf6798fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6799000, 0x7ffcf6799fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf679a000, 0x7ffcf679bfff] 8KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf679c000, 0x7ffcf699afff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf699b000, 0x7ffcf699bfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf699c000, 0x7ffcf69a4fff] 36KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf69a5000, 0x7ffcf6ba3fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6ba4000, 0x7ffcf6ba4fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6ba5000, 0x7ffcf6bb4fff] 64KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6bb5000, 0x7ffcf6db4fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6db5000, 0x7ffcf6db5fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6db6000, 0x7ffcf6db7fff] 8KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6db8000, 0x7ffcf6fb6fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6fb7000, 0x7ffcf6fb7fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6fb8000, 0x7ffcf6fb9fff] 8KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf6fba000, 0x7ffcf71b8fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf71b9000, 0x7ffcf71b9fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf71ba000, 0x7ffcf72eefff] 1236KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf72ef000, 0x7ffcf74eefff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf74ef000, 0x7ffcf74f4fff] 24KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf74f5000, 0x7ffcf763dfff] 1316KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf763e000, 0x7ffcf783dfff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf783e000, 0x7ffcf7841fff] 16KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7842000, 0x7ffcf7842fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7843000, 0x7ffcf7847fff] 20KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7848000, 0x7ffcf785afff] 76KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf785b000, 0x7ffcf7a5afff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7a5b000, 0x7ffcf7a5bfff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7a5c000, 0x7ffcf7a5cfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7a5d000, 0x7ffcf7a5efff] 8KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7a5f000, 0x7ffcf7a75fff] 92KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7a76000, 0x7ffcf7c74fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7c75000, 0x7ffcf7c75fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7c76000, 0x7ffcf7d1cfff] 668KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7d1d000, 0x7ffcf7f1cfff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7f1d000, 0x7ffcf7f27fff] 44KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf7f28000, 0x7ffcf807bfff] 1360KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf807c000, 0x7ffcf827afff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf827b000, 0x7ffcf8284fff] 40KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8285000, 0x7ffcf8285fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8286000, 0x7ffcf8348fff] 780KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8349000, 0x7ffcf8547fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8548000, 0x7ffcf8549fff] 8KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf854a000, 0x7ffcf854cfff] 12KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf854d000, 0x7ffcf874bfff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf874c000, 0x7ffcf874cfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf874d000, 0x7ffcf8790fff] 272KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8791000, 0x7ffcf8990fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8991000, 0x7ffcf8992fff] 8KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8993000, 0x7ffcf89c2fff] 192KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf89c3000, 0x7ffcf8bc1fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8bc2000, 0x7ffcf8bc3fff] 8KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8bc4000, 0x7ffcf8c45fff] 520KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8c46000, 0x7ffcf8e44fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8e45000, 0x7ffcf8e4afff] 24KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8e4b000, 0x7ffcf8e92fff] 288KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf8e93000, 0x7ffcf9092fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9093000, 0x7ffcf9095fff] 12KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9096000, 0x7ffcf9114fff] 508KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9115000, 0x7ffcf9314fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9315000, 0x7ffcf9317fff] 12KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9318000, 0x7ffcf9391fff] 488KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9392000, 0x7ffcf9590fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9591000, 0x7ffcf9592fff] 8KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9593000, 0x7ffcf9593fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9594000, 0x7ffcf959efff] 44KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf959f000, 0x7ffcf979efff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf979f000, 0x7ffcf979ffff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf97a0000, 0x7ffcf9821fff] 520KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9822000, 0x7ffcf9a20fff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9a21000, 0x7ffcf9a21fff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9a22000, 0x7ffcf9a22fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9a23000, 0x7ffcf9a3cfff] 104KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9a3d000, 0x7ffcf9c3cfff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9c3d000, 0x7ffcf9c3dfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9c3e000, 0x7ffcf9c6afff] 180KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9c6b000, 0x7ffcf9e6afff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9e6b000, 0x7ffcf9e6bfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9e6c000, 0x7ffcf9e89fff] 120KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcf9e8a000, 0x7ffcfa089fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa08a000, 0x7ffcfa08cfff] 12KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa08d000, 0x7ffcfa128fff] 624KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa129000, 0x7ffcfa328fff] 2048KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa329000, 0x7ffcfa32dfff] 20KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa32e000, 0x7ffcfa71cfff] 4028KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa71d000, 0x7ffcfa91bfff] 2044KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa91c000, 0x7ffcfa926fff] 44KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa927000, 0x7ffcfa928fff] 8KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa929000, 0x7ffcfa945fff] 116KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa946000, 0x7ffcfa946fff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa947000, 0x7ffcfa949fff] 12KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa94a000, 0x7ffcfa94afff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa94b000, 0x7ffcfa94efff] 16KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa94f000, 0x7ffcfa957fff] 36KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa958000, 0x7ffcfa95afff] 12KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa95b000, 0x7ffcfa95bfff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa95c000, 0x7ffcfa95efff] 12KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa95f000, 0x7ffcfa95ffff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa960000, 0x7ffcfa98dfff] 184KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa98e000, 0x7ffcfa990fff] 12KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa991000, 0x7ffcfa992fff] 8KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa993000, 0x7ffcfa995fff] 12KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa996000, 0x7ffcfa99efff] 36KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa99f000, 0x7ffcfa9a0fff] 8KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa9a1000, 0x7ffcfa9a6fff] 24KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa9a7000, 0x7ffcfa9aafff] 16KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa9ab000, 0x7ffcfa9bdfff] 76KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa9be000, 0x7ffcfa9c0fff] 12KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa9c1000, 0x7ffcfa9d4fff] 80KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa9d5000, 0x7ffcfa9edfff] 100KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfa9ee000, 0x7ffcfaa06fff] 100KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfaa07000, 0x7ffcfaa07fff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfaa08000, 0x7ffcfaa08fff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfaa09000, 0x7ffcfaa17fff] 60KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfaa18000, 0x7ffcfaa1cfff] 20KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfaa1d000, 0x7ffcfab1bfff] 1020KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfab1c000, 0x7ffcfab1cfff] 4KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfab1d000, 0x7ffcfab26fff] 40KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfab27000, 0x7ffcfab28fff] 8KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfab29000, 0x7ffcfab2ffff] 28KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfab30000, 0x7ffcfab3dfff] 56KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfab3e000, 0x7ffcfab3efff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfab3f000, 0x7ffcfab40fff] 8KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfab41000, 0x7ffcfab41fff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfab42000, 0x7ffcfab44fff] 12KiB
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfab45000, 0x7ffcfab45fff] 4KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7ffcfab46000, 0x7ffcfab46fff] 4KiB +
8519528KiB hole
09-05-30 00:31:24 (MESSAGE): VMM [0x7fff02b21000, 0x7fff02b30fff] 64KiB
(foreign)
09-05-30 00:31:24 (MESSAGE): VMM [0x7fff02b31000, 0x7fff02b45fff] 84KiB +
740KiB hole
09-05-30 00:31:24 (MESSAGE): VMM [0x7fff02bff000, 0x7fff02bfffff] 4KiB
(foreign) + 18014261074667520KiB hole
09-05-30 00:31:24 (MESSAGE): VMM [0xffffffffff600000, 0xffffffffff600fff] 4KiB
(foreign)
FATAL: Assertion failure in vmm.c:755: "foreign"
CRASH (pid=23954) by SIGABRT
Aborted

Stack trace (I hope I got this right)
=======================
#0 0x00007fde690d0065 in raise () from /lib/libc.so.6
#1 0x00007fde690d3153 in abort () from /lib/libc.so.6
#2 0x00000000005e2d76 in assertion_failure (data=0x74d4b0) at
fast_assert.c:96
#3 0x00000000006213c5 in pmap_insert_region (pm=0xa35980,
start=0x7fde63a48000, size=8192, foreign=0) at vmm.c:755
#4 0x0000000000620b05 in pmap_insert (pm=0xa35980,
start=0x7fde63a48000, size=8192) at vmm.c:488
#5 0x0000000000620bc1 in alloc_pages (size=8192, update_pmap=1) at
vmm.c:520
#6 0x00000000006247a7 in vmm_alloc (size=8192) at vmm.c:2055
#7 0x00000000006269fe in subzone_alloc_arena (sz=0xf9d790, size=8160)
at zalloc.c:445
#8 0x0000000000626d1a in zn_create (zone=0xf9d790, size=136, hint=60)
at zalloc.c:597
#9 0x000000000062701d in zcreate (size=136, hint=60) at zalloc.c:696
#10 0x00000000006271bb in zget (size=136, hint=60) at zalloc.c:784
#11 0x000000000062582b in wzone_get (rounded=136) at walloc.c:119
#12 0x0000000000625923 in walloc (size=136) at walloc.c:156
#13 0x000000000050a1fd in verify_new (hash=0x689ae0) at verify.c:295
#14 0x000000000050ae03 in verify_sha1_init () at verify_sha1.c:120
#15 0x0000000000414ab2 in main (argc=1, argv=0x7fff746ec9a8) at
main.c:1447

I hope this is of any use.

Hauke

------------------------------

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 29, Issue 5
*************************************************

gtk-gnutella-devel Digest, Vol 29, Issue 4

2009-05-29T15:09:55Z

> Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel:
> :Hauke Hachmann wrote:
> :> On Friday 29 May 2009, Christian Biere wrote:
> :> > This is probably fixed in SVN since r16807 now.
> :
> :> Nope, the newest revision (16813) still crashes on startup.
> :
> :Indeed, I can still reproduce the issues with Help->FAQ but
> :it takes a bit longer than before.
>
> This is because vmm_munmap(), in its present form, was wrong. I could
> swear I had written it correctly, otherwise it's a stupid mistake, sorry.

This was actually my mistake. I don't like testing against '-1' when the
only successful return value is zero. I added a warning in case of failure
now, which would have made this inverted logic of mine obvious sooner.

I doubt this fixes Hauke's issue though. The assertion failure seems to
imply that mmap() didn't like the hint.

--
Christian

------------------------------

Message: 5
Date: Fri, 29 May 2009 20:52:42 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Crash at startup
To: gtk-gnutella-devel@...
Message-ID: <gvphuq$8jg$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel:
:I doubt this fixes Hauke's issue though. The assertion failure seems to
:imply that mmap() didn't like the hint.

Only he can tell that, but my guess is that the hint was falling in a
newly mapped region that was not loaded in the kernel pmap, and this
triggered a reload. Then it hit my bug whereby I called vmm_reserve_stack(0)
and forgot to move down the pre-condition to the region where we have no
kernel map loaded in that vmm_reserve_stack() routine.

What made me look at vmm_munmap() was the behaviour you described, that
was working for me previously. I disabled locally my kernel map loading,
hit "Help -> FAQ" and boom. I had the bug.

Raphael

------------------------------

Message: 6
Date: Fri, 29 May 2009 23:37:11 +0200
From: Hauke Hachmann <haxe@...>
Subject: Re: [gtk-gnutella-devel] Crash at startup
To: gtk-gnutella-devel@...
Message-ID: <200905292337.11528.haxe@...>
Content-Type: Text/Plain; charset="iso-8859-1"

On Friday 29 May 2009, Christian Biere wrote:
> I couldn't reproduce this. Not even on a 32-bit *inux machine.
> You're using gtk-gnutella on a 64-bit *inux machine, right?

Correct, I am using x86-64 Linux (current Debian "testing", which means
software versions roughly being: kernel 2.6.26, glibc 2.9, GCC 4.3.3).

On Friday 29 May 2009, Christian Biere wrote:
> I doubt this fixes Hauke's issue though.

Again correct (unfortunately). Revision 16818 still crashes at startup.
The message this time:

FATAL: Assertion failure in vmm.c:755: "foreign"

Hauke

------------------------------

Message: 7
Date: Fri, 29 May 2009 23:46:05 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Crash at startup
To: gtk-gnutella-devel@...
Message-ID: <20090529214605.GA8504@...>
Content-Type: text/plain; charset=utf-8

Hauke Hachmann wrote:

> On Friday 29 May 2009, Christian Biere wrote:
> > I couldn't reproduce this. Not even on a 32-bit *inux machine.
> > You're using gtk-gnutella on a 64-bit *inux machine, right?
>
> Correct, I am using x86-64 Linux (current Debian "testing", which means
> software versions roughly being: kernel 2.6.26, glibc 2.9, GCC 4.3.3).
>
> On Friday 29 May 2009, Christian Biere wrote:
> > I doubt this fixes Hauke's issue though.
>
> Again correct (unfortunately). Revision 16818 still crashes at startup.
> The message this time:
>
> FATAL: Assertion failure in vmm.c:755: "foreign"

Could you provide a stack trace and a cat of /proc/self/maps?
Maybe any of it gives some obvious glue.

--
Christian

------------------------------

Message: 8
Date: Fri, 29 May 2009 22:09:22 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Crash at startup
To: gtk-gnutella-devel@...
Message-ID: <gvpmei$jd4$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel:
:Hauke Hachmann wrote:
:> On Friday 29 May 2009, Christian Biere wrote:
:> > I couldn't reproduce this. Not even on a 32-bit *inux machine.
:> > You're using gtk-gnutella on a 64-bit *inux machine, right?
:>
:> Correct, I am using x86-64 Linux (current Debian "testing", which means
:> software versions roughly being: kernel 2.6.26, glibc 2.9, GCC 4.3.3).
:>
:> On Friday 29 May 2009, Christian Biere wrote:
:> > I doubt this fixes Hauke's issue though.
:>
:> Again correct (unfortunately). Revision 16818 still crashes at startup.
:> The message this time:
:>
:> FATAL: Assertion failure in vmm.c:755: "foreign"
:
:Could you provide a stack trace and a cat of /proc/self/maps?
:Maybe any of it gives some obvious glue.

And please, could you turn on vmm_debug to 1 and show the last "VMM" messages
before the crash?

Thanks,
Raphael

------------------------------

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 29, Issue 4
*************************************************

gtk-gnutella-devel Digest, Vol 29, Issue 3

2009-05-29T10:52:15Z

> Matthew Lye wrote:
>> On 13-May-09, at 1:46 AM, Christian Biere wrote:
>>> Do you get this warning for every incoming connection or just for
>>> some?
>
>> Just for some, albeit fairly frequently. (That said, it's happening
>> with every call to getpeername$UNIX2003.)
>
> You could call getpeername() unconditonally after each successful
> accept() to ensure it's not just a problem with getpeername().
> However,
> getpeername() wouldn't be called if accept() had provided an address
> as it should.

Under these circumstances, getpeername() does set a plausible
address. It's setting 0.0.0.0 and failing only when called after
accept(). Looking at the warnings in the code, there should be a
different warning if getpeername() ever succeeds when accept() fails;
this does not occur. I'll check the network stuff next session.

------------------------------

Message: 5
Date: Fri, 29 May 2009 01:47:34 +0200
From: Hauke Hachmann <haxe@...>
Subject: [gtk-gnutella-devel] Crash at startup
To: gtk-gnutella-devel@...
Message-ID: <200905290147.34313.haxe@...>
Content-Type: Text/Plain; charset="us-ascii"

Hi list,

I have a problem with latest svn revision 16799: I cannot even start the
application. Directly after invokation I get this error:

** ERROR **: pmap already contains the new region
aborting...
CRASH (pid=14792) by SIGABRT
Aborted

Any ideas?

Hauke

------------------------------

Message: 6
Date: Fri, 29 May 2009 15:53:34 +0200
From: Hauke Hachmann <haxe@...>
Subject: Re: [gtk-gnutella-devel] Crash at startup
To: Matthew Lye <mlye@...>,
gtk-gnutella-devel@...
Message-ID: <200905291553.34538.haxe@...>
Content-Type: Text/Plain; charset="iso-8859-1"

On Friday 29 May 2009, Matthew Lye wrote:
> > I have a problem with latest svn revision 16799:...
[...]
>
> That error message is from "lib/vmm.c", which was undergoing some
> work as recently as revision 16799.
> Just roll back to 16798 for the day if you need your client right
> now.

That did not work. The error must have been introduced earlier. I then
took the time and bisected the error back to r16786. Everything before
that works fine, everything starting from r16786 is broken.

Going with r16785 for the moment.

Bye,

Hauke

------------------------------

Message: 7
Date: Fri, 29 May 2009 18:09:51 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Crash at startup
To: gtk-gnutella-devel@...
Message-ID: <20090529160951.GA21925@...>
Content-Type: text/plain; charset=utf-8

Hauke Hachmann wrote:

> On Friday 29 May 2009, Matthew Lye wrote:
> > > I have a problem with latest svn revision 16799:...
> [...]
> >
> > That error message is from "lib/vmm.c", which was undergoing some
> > work as recently as revision 16799.
> > Just roll back to 16798 for the day if you need your client right
> > now.
>
> That did not work. The error must have been introduced earlier. I then
> took the time and bisected the error back to r16786. Everything before
> that works fine, everything starting from r16786 is broken.
>
> Going with r16785 for the moment.

I can confirm this but I'm only seeing crashes when vmm_mmap() is used.
This happens either by uploads or when loading the FAQ under Help->FAQ
in the GUI. The crash doesn't occur immediately but a bit afterwards
because there seems to be something screwed up with respect to tracking
foreign regions.

If it happens on *inux more frequently, it might be because
/proc/self/maps is used then to find foreign regions.

--
Christian

------------------------------

Message: 8
Date: Fri, 29 May 2009 19:37:05 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Crash at startup
To: gtk-gnutella-devel@...
Message-ID: <20090529173705.GA19545@...>
Content-Type: text/plain; charset=utf-8

Hauke Hachmann wrote:

This is probably fixed in SVN since r16807 now.

--
Christian

------------------------------

Message: 9
Date: Fri, 29 May 2009 19:52:05 +0200
From: Hauke Hachmann <haxe@...>
Subject: Re: [gtk-gnutella-devel] Crash at startup
To: gtk-gnutella-devel@...
Message-ID: <200905291952.05124.haxe@...>
Content-Type: Text/Plain; charset="iso-8859-1"

On Friday 29 May 2009, Christian Biere wrote:
> This is probably fixed in SVN since r16807 now.

Nope, the newest revision (16813) still crashes on startup. But with a
different error message this time:

FATAL: Assertion failure in vmm.c:2311: "amount != 0"

h

------------------------------

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 29, Issue 3
*************************************************

gtk-gnutella-devel Digest, Vol 29, Issue 2

2009-05-12T22:40:37Z

> For a long time I've seen the following warning produced many, many
> times per session:
>
> > 09-05-12 22:01:00 (WARNING): getpeername() failed: Invalid argument
>
> I just got around to checking into it with dtrace, and it appears that
> getpeername() is not actually being called when this warning comes up.
>
> This would imply that the either of the two following asserts in the
> function socket_addr_getpeername(...) (located in core/sockets.c: line
> 1981) always fails:
> > g_return_val_if_fail(p_addr, -1);
> > g_return_val_if_fail(fd >= 0, -1);

If that's the case you should see the relevant warnings on stderr.
You can also try to remove the lines to verify your thesis.

It is also possible that the userland code of getpeername() doesn't
like some of the passed arguments, so that the syscall is never
issued and you probably don't see anything with dtrace. If it
happens often but not always it could be an alignment issue.

--
Christian

------------------------------

Message: 5
Date: Wed, 13 May 2009 05:31:19 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] getpeername() failed warning:
getpeername not being called.
To: gtk-gnutella-devel@...
Message-ID: <20090513033119.GC692@...>
Content-Type: text/plain; charset=utf-8

Christian Biere wrote:

> Matthew Lye wrote:
> > For a long time I've seen the following warning produced many, many
> > times per session:
> >
> > > 09-05-12 22:01:00 (WARNING): getpeername() failed: Invalid argument
> >
> > I just got around to checking into it with dtrace, and it appears that
> > getpeername() is not actually being called when this warning comes up.
> >
> > This would imply that the either of the two following asserts in the
> > function socket_addr_getpeername(...) (located in core/sockets.c: line
> > 1981) always fails:
> > > g_return_val_if_fail(p_addr, -1);
> > > g_return_val_if_fail(fd >= 0, -1);
>
> If that's the case you should see the relevant warnings on stderr.
> You can also try to remove the lines to verify your thesis.
>
> It is also possible that the userland code of getpeername() doesn't
> like some of the passed arguments, so that the syscall is never
> issued and you probably don't see anything with dtrace. If it
> happens often but not always it could be an alignment issue.

It's also thinkable that the connection was only half-established
or reset before getpeername(). You might want to run tcpdump or
similar in parallel to see whether the warnings correlate with
incoming connections and what happens after the first SYN packet.

--
Christian

------------------------------

Message: 6
Date: Wed, 13 May 2009 00:53:58 -0400
From: Matthew Lye <mlye@...>
Subject: Re: [gtk-gnutella-devel] getpeername() failed warning:
getpeername not being called.
To: gtk-gnutella-devel@...
Message-ID: <43935FEC-0457-4D0A-83BD-694481A97306@...>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

On 12-May-09, at 11:26 PM, Christian Biere wrote:
> If that's the case you should see the relevant warnings on stderr.
> You can also try to remove the lines to verify your thesis.

No, no, that would have been clever.

It's more complicated than I thought. There's a "getpeername
$UNIX2003()", which is being called instead of "getpeername()", and it
is this which fails. Presumably known to everyone outside of Apple as
"getpeername()". The arguments being passed it seem okay. A socket
number (I assume), and two addresses. The latter should be a (small)
size, and is in my tests always 0x10 or 0x1e. I don't know the
structure of the former, but it always starts with 0x1002 followed by
3 8-byte words of zeros in the first case, and 0x1c1e followed by 6 8-
byte words of zeros in the second case.

The warnings didn't seem to correlate with anything unusual incoming
bearing a SYN bit. I'm less than handy with tcpdump, I'll try
tomorrow with fewer peers in the mix. Is there anything in particular
you're thinking of?

------------------------------

Message: 7
Date: Wed, 13 May 2009 07:32:34 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] getpeername() failed warning:
getpeername not being called.
To: gtk-gnutella-devel@...
Message-ID: <20090513053230.GA21209@...>
Content-Type: text/plain; charset=utf-8

Matthew Lye wrote:

> On 12-May-09, at 11:26 PM, Christian Biere wrote:
> > If that's the case you should see the relevant warnings on stderr.
> > You can also try to remove the lines to verify your thesis.
>
> No, no, that would have been clever.
>
> It's more complicated than I thought. There's a "getpeername
> $UNIX2003()", which is being called instead of "getpeername()", and it
> is this which fails. Presumably known to everyone outside of Apple as
> "getpeername()". The arguments being passed it seem okay. A socket
> number (I assume), and two addresses. The latter should be a (small)
> size, and is in my tests always 0x10 or 0x1e. I don't know the
> structure of the former, but it always starts with 0x1002 followed by
> 3 8-byte words of zeros in the first case, and 0x1c1e followed by 6 8-
> byte words of zeros in the second case.
>
> The warnings didn't seem to correlate with anything unusual incoming
> bearing a SYN bit. I'm less than handy with tcpdump, I'll try
> tomorrow with fewer peers in the mix. Is there anything in particular
> you're thinking of?

There must be some incoming connection, otherwise the function wouldn't
be called. accept() seems to succeed but doesn't fill in the source
address. Maybe dtrace could show anything useful about this accept()
call because it's already odd enough that it doesn't fill in the
source address.

It is possible that an incoming connection is reset before accept()
is called. Normally, accept() should fail in this case.

Another possibility is that there's an incoming IPv6 connection and
something with the code isn't right. I don't know whether you have
IPv6 connectivity or whether you've configured it to use IPv4 only.

--
Christian

------------------------------

Message: 8
Date: Wed, 13 May 2009 07:46:11 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] getpeername() failed warning:
getpeername not being called.
To: gtk-gnutella-devel@...
Message-ID: <20090513054610.GB21209@...>
Content-Type: text/plain; charset=utf-8

Matthew Lye wrote:
> For a long time I've seen the following warning produced many, many
> times per session:
>
> > 09-05-12 22:01:00 (WARNING): getpeername() failed: Invalid argument
>
> I just got around to checking into it with dtrace, and it appears that
> getpeername() is not actually being called when this warning comes up.

Do you get this warning for every incoming connection or just for some?

--
Christian

------------------------------

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 29, Issue 2
*************************************************

gtk-gnutella-devel Digest, Vol 29, Issue 1

2009-05-10T00:33:41Z

> When building gtk-gnutella-current on NetBSD-5.0rc4/amd64 I get this
> compile error:
>
> cc -c -I../.. -I.. -I/usr/pkg/include/glib/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -DCURDIR=src/lib -O2 -g -pipe -momit-leaf-frame-pointer -W -Wall -Wformat=2 -Wshadow atoms.c
> atoms.c: In function 'atom_get':
> atoms.c:837: error: duplicate case value
> atoms.c:837: error: previously used here
> gmake[3]: *** [atoms.o] Error 1
>
> I think it relates this this entry in config.h
>
> %grep MEM_ALI work/gtk-gnutella/config.h
> /* MEM_ALIGNBYTES:
> #define MEM_ALIGNBYTES 16 /**/
>
> Building the latest gtk-gnutella release, 0.96.5, gives this in the
> generated config.h:

The latest release is actually 0.96.6 although I'd recommend using
0.96.7u from SVN instead because the "stable" release leaks quite
badly.

> %grep 'define MEM_ALI' work/gtk-gnutella-0.96.5/config.h
> #define MEM_ALIGNBYTES 8 /**/

> Changing the config.h file entry 16 to 8 gets me through the build on
> gtk-gnutella-current, but I have not tried starting the binary.

> Investigating the alignbytes detection program embedded in the
> configure script reveals that it is the long double type which bumps up
> the alignment constraint to 16. In the 0.96.5 release, only char and
> double types are checked.

The old detection unit wasn't cross-compilable and suffered from blahism.
It defined MEM_ALIGNBYTES but actually talked about double. I considered
detecting the common maximum alignment constraint for all native types
is more useful and matching the seemingly obvious semantic of "align bytes".
Histerically, the widest type with the strictest alignment constraints
was 'double' but this was in the dark ages before the advent of C99,
maybe even before C89.

gtk-gnutella doesn't use "long double" but some library might, in theory.

> Any comments? I am not really sure how to proceed here.. I assume this
> works fine on other 64bit OSes?

Well, bugs don't exist unless reported. Apparently it does but nobody really
knows. In general, if gtk-gnutella doesn't compile or the compiler reports any
warnings, people should report these as soon as possible.

--
Christian

------------------------------

Message: 3
Date: Mon, 4 May 2009 23:45:59 +0200
From: Lars Nordlund <lars.nordlund@...>
Subject: Re: [gtk-gnutella-devel] STATIC_ASSERT related to maximum
alignment
To: gtk-gnutella-devel@...
Cc: christianbiere@...
Message-ID: <20090504234559.6f79dd01@laphroaig>
Content-Type: text/plain; charset=US-ASCII

On Sun, 3 May 2009 02:18:49 +0200
Christian Biere <christianbiere@...> wrote:

> The latest release is actually 0.96.6 although I'd recommend using
> 0.96.7u from SVN instead because the "stable" release leaks quite
> badly.

Yes, you are correct. I blindly thought that pkgsrc/net/gtk-gnutella
was up-to-date. :-)

> The old detection unit wasn't cross-compilable and suffered from blahism.
> It defined MEM_ALIGNBYTES but actually talked about double. I considered
> detecting the common maximum alignment constraint for all native types
> is more useful and matching the seemingly obvious semantic of "align bytes".
> Histerically, the widest type with the strictest alignment constraints
> was 'double' but this was in the dark ages before the advent of C99,
> maybe even before C89.
>
> gtk-gnutella doesn't use "long double" but some library might, in theory.

I see.

> > Any comments? I am not really sure how to proceed here.. I assume this
> > works fine on other 64bit OSes?
>
> Well, bugs don't exist unless reported. Apparently it does but nobody really
> knows. In general, if gtk-gnutella doesn't compile or the compiler reports any
> warnings, people should report these as soon as possible.

I commented out the long double type from the Configure script test,
and have built a trunk version of gtk-gnutella. It has been running
stable for a couple of hours. Not much of a formal verification, but at
least an "it works here"-report..

Best regards,
Lars Nordlund

------------------------------

Message: 4
Date: Tue, 5 May 2009 00:15:30 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] STATIC_ASSERT related to maximum
alignment
To: gtk-gnutella-devel@...
Message-ID: <20090504221530.GA16259@...>
Content-Type: text/plain; charset=utf-8

Lars Nordlund wrote:
> On Sun, 3 May 2009 02:18:49 +0200
> Christian Biere <christianbiere@...> wrote:

> I commented out the long double type from the Configure script test,
> and have built a trunk version of gtk-gnutella. It has been running
> stable for a couple of hours. Not much of a formal verification, but at
> least an "it works here"-report..

Well, I think I had just fixed it before responding to your mail. So it
shouldn't be necessary to comment it out any longer. Don't you see any
warnings from the compiler at all?

Unfortunately, x86 platforms are no good for testing alignment correctness
because they're too forgiving.

By the way, practically there's no point for this test at all, as it's
MEM_ALIGNBYTES is a compile-time evaluable constant and a similar macro
could be used to evaluate alignment constraint for specific types instead
of using the maximum always - which might be overkill and wasting memory.

--
Christian

------------------------------

Message: 5
Date: Mon, 4 May 2009 21:34:33 -0400
From: Matthew Lye <mlye@...>
Subject: [gtk-gnutella-devel] Static assert about atoms.
To: gtk-gnutella-devel@...
Message-ID: <F7F2531A-D0EE-48FF-B838-1BDFFA750B4B@...>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Hey there,

I was just trying to get Darwin's llvm-gcc (low level virtual machine
based gcc) going on my machine, and I'm getting a static assert at
line 832 of "atoms.c"; the arena offset isn't aligning to modulo 16
bytes. (A recent change to alignment in llvm-gcc 4.2).

http://devworld.apple.com/releasenotes/DeveloperTools/RN-llvm-gcc/index.html
for latest changes.

------------------------------

Message: 6
Date: Tue, 5 May 2009 10:48:33 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Static assert about atoms.
To: gtk-gnutella-devel@...
Message-ID: <20090505084833.GA29680@...>
Content-Type: text/plain; charset=utf-8

Matthew Lye wrote:
> I was just trying to get Darwin's llvm-gcc (low level virtual machine
> based gcc) going on my machine, and I'm getting a static assert at
> line 832 of "atoms.c"; the arena offset isn't aligning to modulo 16
> bytes. (A recent change to alignment in llvm-gcc 4.2).

My previous attempt to fix the bug reported by Lars Nordlund was nonsense.
I think it makes more sense this time.

--
Christian

------------------------------

Message: 7
Date: Sat, 9 May 2009 22:48:10 -0400
From: Matthew Lye <mlye@...>
Subject: [gtk-gnutella-devel] warning: "size_t not int" in
dht/routing.c
To: gtk-gnutella-devel@...
Message-ID: <733A0D02-92A7-42DE-A2DF-CB392C332FAE@...>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
delsp=yes

Cosmetic in this instance I guess, but hopefully no-one's depending on
size_t always equalling int.

routing.c: In function ?dht_compute_size_estimate?:
routing.c:2425: warning: format ?%d? expects type ?int?, but argument
4 has type ?long unsigned int?

from /Users/mlye/prj/gtk-fast/src/dht/routing.cc:
line 2333:
> size_t i;

...
line 2425:
> g_message("DHT sparseness over %d nodes is %s = %f (%f)",
> i - 1, kuid_to_hex_string(&sparseness),
> kuid_to_double(&sparseness), ds / s);

------------------------------

Message: 8
Date: Sun, 10 May 2009 07:12:12 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] warning: "size_t not int" in
dht/routing.c
To: gtk-gnutella-devel@...
Message-ID: <gu5uoc$2ne$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
:Cosmetic in this instance I guess, but hopefully no-one's depending on
:size_t always equalling int.
:
:routing.c: In function ?dht_compute_size_estimate?:
:routing.c:2425: warning: format ?%d? expects type ?int?, but argument
:4 has type ?long unsigned int?

Thanks, fixed in r16705.

Raphael

------------------------------

Message: 9
Date: Sun, 10 May 2009 07:13:53 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] FATAL: Assertion failure in
atoms.c:928: "size > 0" in 0.96.6
To: gtk-gnutella-devel@...
Message-ID: <gu5urh$2ne$2@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Jochen Kemnade <jochenkemnade@...> from ml.softs.gtk-gnutella.devel:
:I encounter this error every time gtk-gnutella has run for some time
:(about half an hour, roughly). Unfortunately I cannot tell how to
:reproduce it, but it seems to happen without user interaction. Maybe,
:the following backtrace provides more details:
:
:FATAL: Assertion failure in atoms.c:928: "size > 0"

Are you still seeing this with the DHT code enabled?

You'd better test it thoroughly, because the next release is likely to
make DHT code enabled by default...

Raphael

------------------------------

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 29, Issue 1
*************************************************

gtk-gnutella-devel Digest, Vol 28, Issue 4

2009-04-16T15:31:59Z

> While trying to compile todays SVN (without remote interface), I get
> this:
>
> cc -o gtk-gnutella main.o
> if/bridge/ui2c.o if/bridge/c2ui.o
> if/gnet_property.o if/gui_property.o -Lshell -lshell -Lcore -lcore -Ldht
> -ldht -Lui/gtk -lgtk-common -lgtkx -lgtk-common -ldht -lcore -Llib
> -lshared -Lsdbm -lsdbm -lshared -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
> -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender
> -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lX11
> -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgobject-2.0 -lglib-2.0
> -lxml2 -lgnutls -O2 -g -march=pentium4 -L/usr/local/lib -lz -lresolv
> shell/libshell.a(memory.o): In function `shell_exec_memory_dump':
> /home/mroos/compile/gtk-gnutella/src/shell/memory.c:114: undefined
> reference to `pointer_to_string'

Thanks. I had missed to commit the change to misc.[ch].

--
Christian

------------------------------

Message: 6
Date: Tue, 14 Apr 2009 19:10:25 -0700
From: Lloyd Bryant <lloydbaz@...>
Subject: [gtk-gnutella-devel] Massive warnings "ISO C forbids
braced-groups within expressions"
To: devlist <gtk-gnutella-devel@...>
Message-ID: <BAY121-W5549BC3CED8BA2C8BB8606CE7D0@...>
Content-Type: text/plain; charset="windows-1252"

Just upgraded to Ubuntu Jaunty (9.04), and when recompiling GtkG (svn 16499), I am seeing tons of the warning message "ISO C forbids braced-groups within expressions". Here's a sampling:

In file included from parq.h:43,
from uploads.c:59:
uploads.h: In function ?upload_check?:
uploads.h:141: warning: ISO C forbids braced-groups within expressions
uploads.h:142: warning: ISO C forbids braced-groups within expressions
uploads.c: In function ?upload_add_upload_added_listener?:
uploads.c:200: warning: ISO C forbids braced-groups within expressions
uploads.c:200: warning: ISO C forbids braced-groups within expressions
uploads.c: In function ?upload_remove_upload_added_listener?:
uploads.c:206: warning: ISO C forbids braced-groups within expressions
uploads.c:206: warning: ISO C forbids braced-groups within expressions
uploads.c: In function ?upload_add_upload_removed_listener?:
uploads.c:212: warning: ISO C forbids braced-groups within expressions
uploads.c:212: warning: ISO C forbids braced-groups within expressions
uploads.c: In function ?upload_remove_upload_removed_listener?:
uploads.c:218: warning: ISO C forbids braced-groups within expressions
uploads.c:218: warning: ISO C forbids braced-groups within expressions

In file included from ../lib/prop.h:31,
from ../if/gnet_property.h:32,
from verify.c:43:
../lib/host_addr.h: In function ?net_type_to_pf?:
../lib/host_addr.h:72: warning: ISO C forbids braced-groups within expressions
../lib/host_addr.h: In function ?net_type_to_af?:
../lib/host_addr.h:90: warning: ISO C forbids braced-groups within expressions
../lib/host_addr.h: In function ?host_addr_initialized?:
../lib/host_addr.h:194: warning: ISO C forbids braced-groups within expressions
../lib/host_addr.h: In function ?net_type_to_string?:
../lib/host_addr.h:207: warning: ISO C forbids braced-groups within expressions
../lib/host_addr.h: In function ?host_addr_equal?:
../lib/host_addr.h:276: warning: ISO C forbids braced-groups within expressions
../lib/host_addr.h: In function ?host_addr_cmp?:
../lib/host_addr.h:317: warning: ISO C forbids braced-groups within expressions
../lib/host_addr.h: In function ?host_addr_matches?:
../lib/host_addr.h:358: warning: ISO C forbids braced-groups within expressions
../lib/host_addr.h: In function ?is_host_addr?:
../lib/host_addr.h:376: warning: ISO C forbids braced-groups within expressions

It seems that every assert throughout GtkG is triggering this warning (and there are a LOT of them :)).

I suspect this is a result of picking up a new gcc version with the upgrade. Here's the version I'm using:

lloyd@dell:/usr/local/src/gtk-gnutella$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)

Any clues?

Lloyd B.

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 7
Date: Fri, 17 Apr 2009 00:34:29 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Massive warnings "ISO C forbids
braced-groups within expressions"
To: gtk-gnutella-devel@...
Message-ID: <20090416223429.GC18437@...>
Content-Type: text/plain; charset=utf-8

Lloyd Bryant wrote:
> Just upgraded to Ubuntu Jaunty (9.04), and when recompiling GtkG (svn 16499),
> I am seeing tons of the warning message "ISO C forbids braced-groups within
> expressions". Here's a sampling:

> In file included from parq.h:43,
> from uploads.c:59:
> uploads.h: In function ?upload_check?:
> uploads.h:141: warning: ISO C forbids braced-groups within expressions
> uploads.h:142: warning: ISO C forbids braced-groups within expressions
> It seems that every assert throughout GtkG is triggering this warning (and
> there are a LOT of them :)).

Do you compile with GLib 1.2?

> I suspect this is a result of picking up a new gcc version with the upgrade.

No, it's caused by -pedantic in the C compiler flags.

> Any clues?

GCC is right. This particular warning is quite useless here and GLib 2.x manages
to avoid or at least suppress it. Unfortunately, there doesn't seem to be a
compiler switch to supress it. It doesn't even seem to be possible to override
-pedantic unlike other switches. At least, I have no glue.

Overall though, use of -pedantic makes it easier to keep the code portable and
ISO-compliant, as far as reasonable and possible.

--
Christian

------------------------------

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 28, Issue 4
*************************************************

gtk-gnutella-devel Digest, Vol 28, Issue 3

2009-04-11T14:28:46Z

> $ cd gtk-gnutella/contrib/bitzify
> $ make && sudo make install
> cc -W -Wall -Wformat=2 -Wshadow -O2 -g `pkg-config taglib --cflags --libs` -ltag_c -o audiotags audiotags.c
> audiotags.c: In function ?main?:
> audiotags.c:227: warning: ignoring return value of ?freopen?, declared with attribute warn_unused_result
> cc -W -Wall -Wformat=2 -Wshadow -O2 -g first20.c -o first20
> cc -W -Wall -Wformat=2 -Wshadow -O2 -g urlencode.c -o urlencode
> cc -W -Wall -Wformat=2 -Wshadow -O2 -g htmlencode.c -o htmlencode
> /bin/sh run_checks.sh
> cp -i -- first20 urlencode htmlencode bitzify "/usr/local/bin/"
> cp: cannot stat `bitzify': No such file or directory
> make: *** [install] Error 1
>
> There's no bitzify in bitzify! Unless I missed something really obvious.
> Is Bitzify a shell script or what? Where do I get it?

The file was missing for no apparent reason. Yes, it's a shell script.

--
Christian

------------------------------

Message: 7
Date: Sat, 11 Apr 2009 12:37:58 +0200
From: Jochen Kemnade <jochenkemnade@...>
Subject: [gtk-gnutella-devel] FATAL: Assertion failure in atoms.c:928:
"size > 0" in 0.96.6
To: gtk-gnutella-devel@...
Message-ID: <49E07306.6090908@...>
Content-Type: text/plain; charset=UTF-8

Hello,

I encounter this error every time gtk-gnutella has run for some time
(about half an hour, roughly). Unfortunately I cannot tell how to
reproduce it, but it seems to happen without user interaction. Maybe,
the following backtrace provides more details:

FATAL: Assertion failure in atoms.c:928: "size > 0"

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f37a4625780 (LWP 13490)]
0x00007f37a0de5fb5 in raise () from /lib/libc.so.6
(gdb) bt full
#0 0x00007f37a0de5fb5 in raise () from /lib/libc.so.6
No symbol table info available.
#1 0x00007f37a0de7bc3 in abort () from /lib/libc.so.6
No symbol table info available.
#2 0x00000000005b08e3 in assertion_failure (data=<value optimized out>)
at fast_assert.c:96
No locals.
#3 0x00000000005a86f9 in atom_free (type=ATOM_STRING,
key=0x7f37983c88f0) at atoms.c:928
size = <value optimized out>
a = <value optimized out>
assertion_data_ = {file = 0x65cce7 "atoms.c", expr = 0x65ccfd "key !=
NULL", line = 924}
assertion_data_ = {file = 0x65cce7 "atoms.c",
expr = 0x65cac8 "(int) type >= 0 && (guint) type <
G_N_ELEMENTS(atoms)", line = 925}
assertion_data_ = {file = 0x65cce7 "atoms.c", expr = 0x670182 "size >
0", line = 928}
assertion_data_ = {file = 0x65cce7 "atoms.c", expr = 0x65ccef
"a->refcnt > 0", line = 931}
#4 0x0000000000516765 in rpc_cb_free (rcb=0x7f37985d8480,
can_remove=<value optimized out>,
in_shutdown=0) at ../lib/atoms.h:119
No locals.
#5 0x00000000005aca18 in cq_expire (cq=0x15d2730, ev=0x0) at cq.c:446
fn = (cq_service_t) 0x516850 <rpc_timed_out>
arg = (gpointer) 0x7f37985d8480
assertion_data_ = {file = 0x65e8d8 "cq.c", expr = 0x63073f "fn", line =
436}
#6 0x00000000005acb48 in cq_clock (cq=0x15d2730, elapsed=<value
optimized out>) at cq.c:523
bucket = 1056
last_bucket = 1058
ch = (struct chash *) 0x15d6960
ev = (cevent_t *) 0x34b2
assertion_data_ = {file = 0x65e8d8 "cq.c", expr = 0x65e8f4 "elapsed >=
0", line = 469}
assertion_data_ = {file = 0x65e8d8 "cq.c", expr = 0x65e8dd
"cq->cq_current == NULL",
line = 470}
#7 0x00000000005acc35 in callout_timer (unused_p=<value optimized out>)
at cq.c:567
tv = {tv_sec = 1239444042, tv_usec = 750524}
last_period = {tv_sec = 1239444042, tv_usec = 750524}
#8 0x00007f37a1bbe97b in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#9 0x00007f37a1bbe20a in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
No symbol table info available.
#10 0x00007f37a1bc18e0 in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#11 0x00007f37a1bc1dad in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#12 0x00007f37a3f7e9f7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#13 0x000000000052511d in main_gui_run (geometry_spec=0x0) at main.c:693
now = 1239440020
#14 0x00000000004138e2 in main (argc=1, argv=0x7fffac661a28) at main.c:1458
No locals.

I don't know if it is relevant, but I run a 64-bit Ubuntu 9.04 system.
If I can provide any more info, feel free to ask.

Regards,
Jochen

------------------------------

Message: 8
Date: Sat, 11 Apr 2009 23:30:46 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] FATAL: Assertion failure in
atoms.c:928: "size > 0" in 0.96.6
To: gtk-gnutella-devel@...
Message-ID: <20090411213046.GA8477@...>
Content-Type: text/plain; charset=utf-8

Jochen Kemnade wrote:
> I encounter this error every time gtk-gnutella has run for some time
> (about half an hour, roughly). Unfortunately I cannot tell how to
> reproduce it, but it seems to happen without user interaction.

You've enabled the DHT in your settings, right?

--
Christian

------------------------------

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 28, Issue 3
*************************************************

gtk-gnutella-devel Digest, Vol 28, Issue 2

2009-04-02T08:10:03Z

> Dear Gnutella fans,
>
> Version 0.96.6 stable has been released on sourceforge. You may get it at:
>
> http://downloads.sourceforge.net/gtk-gnutella/gtk-gnutella-0.96.6.tar.bz2
>
> You can also download this release from Gnutella using this link:
>
> magnet:?xt=urn:sha1:GGKBP2G6CBFTHEJ6BCQKV3EMB4RKMEU5&dn=gtk-gnutella-0.96.6.tar.bz2
>
> IMPORTANT

> On Thu, Apr 02, 2009 at 12:22:14PM +0200, Christian Biere wrote:
> > > 2.- If GTKG is not publishing data to the DHT how are we supposed to
> > > download from the provided magnet: link?
> >
> > I wondered myself. Maybe Raphael has a modified version of gtk-gnutella
> > that already supports publishing. Otherwise, if nobody using LimeWire
> > or FrostWire shares the file, it won't be found through the DHT for now.
>
> Good to know I was not the only one wondering about that :) Anyway, you
> get a faster result just by doing a normal search for "gtk-gnutella" and
> now I see that doing that triggers the "orphaned" magnet: download,
> which is cool because I didn't have to double click on the search
> results.

Yes, for popular files that are shared by many peers, it can be useful to
use a combined magnet that provides a "keyword topic", too. So if you append
"&kt=gtk-gnutella-0.96.6.tar.bz2" it will also search Gnutella with a classic
keyword search for the filename. Search results with matching SHA-1 will
then be picked up by the orphaned download that was created by the magnet
link. For rare files it will hardly work because it's unlikely you'll find a
source. Likewise, this is only advisable for files with unambiguous, unique
names.

> > The DHT feature is rather a preview in the current release. There are no GUI
> > controls to inspect the DHT status or configure it. You might want to set
> > dht_debug or dht_lookup_debug to some value above 1-20 to have at least some
> > information on the standard error output respectively your log file. There's
> > diagnostic output showing when DHT lookups are performed, whether they
> > succeeded or failed etc.

> Yes, I have dht_debug = 1 and I see one peculiar thing: ALL the DHT
> FETCH result in "not found". I have three days worth of debug output and
> absolutely all DHT FETCH are "not found", whether they were for "ALOC",
> "PROX" or "BTAL" (?). I don't know if this is normal, but it sure looks
> suspicious to me (which may be due to my ignorance of the DHT's inner
> workings).

That sounds a bit odd, yes. Note that sharing a file isn't actually sufficient.
It has to calculate the SHA-1 first and then store it periodically in the DHT.
LimeWire's publishing strategy seems to be rather sub-optimal and DHT values
expire quickly even for peers with long uptimes and static IP addresses. That
explains why you still won't find all shared files at any time.

> On the other hand, searching for this file:
> http://bitzi.com/lookup/YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C (MLK speech, as
> you suggested) does produce very quick results:
>
> ----- DEBUG LOG -----
> 09-04-02 12:54:56 (MESSAGE): DHT LOOKUP[906] ending value fetch with 0 pending FIND_VALUE RPCs
> 09-04-02 12:54:56 (MESSAGE): DHT LOOKUP[906] terminating value lookup (ALOC) for c344a3ce02b06716a515e59a0277524d202cbba2 with 15 values
> 09-04-02 12:54:56 (MESSAGE): DHT LOOKUP[906] 3.683538 secs, hops=2, in=5673 bytes, out=2106 bytes
> 09-04-02 12:54:56 (MESSAGE): DHT ALOC lookup for YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C returned 15 values
> ----- END DEBUG LOG -----
>
> It doesn't happen this way if I simply search for the urn:sha1: value.

If you just enter a prefix SHA-1 as search, it triggers a classic URN search by
SHA-1 and will rarely gain any results. It doesn't use the DHT (at least for
now) because the DHT doesn't tell as more than addresses of peers. In theory,
we could use a HTTP HEAD request to gather information like filename and
filesize to fabricate a search result.

--
Christian

------------------------------

Message: 6
Date: Thu, 2 Apr 2009 15:09:26 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Version 0.96.6 stable has been
released
To: gtk-gnutella-devel@...
Message-ID: <gr2kf6$sr3$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel:
:Yes, for popular files that are shared by many peers, it can be useful to
:use a combined magnet that provides a "keyword topic", too. So if you append
:"&kt=gtk-gnutella-0.96.6.tar.bz2" it will also search Gnutella with a classic
:keyword search for the filename.

It is my fault, I forgot to append kt. I assumed that the dn would be used
as the search in that case (i.e. that kt would fallback to dn if not supplied).

:> Yes, I have dht_debug = 1 and I see one peculiar thing: ALL the DHT
:> FETCH result in "not found". I have three days worth of debug output and
:> absolutely all DHT FETCH are "not found", whether they were for "ALOC",
:> "PROX" or "BTAL" (?). I don't know if this is normal, but it sure looks
:> suspicious to me (which may be due to my ignorance of the DHT's inner
:> workings).
:
:That sounds a bit odd, yes.

No, this is perfectly NORMAL. In Kademlia, a FIND_NODE and FIND_VALUE are
similar, excepted that FIND_VALUE will return a value if found locally.
A DHT FETCH, as logged by GTKG, is a FIND_VALUE. The semantics is that you
need to converge to the key in the KUID space, so nodes looking for a value
ask your node about closest nodes, and in turn they will contact these
closest nodes to ask them about even more closest nodes to the key until
they have found 20 closest nodes (and none has returned any value, meaning
the value is not found) or one node returns value stored locally.

:If you just enter a prefix SHA-1 as search, it triggers a classic URN search by
:SHA-1 and will rarely gain any results. It doesn't use the DHT (at least for
:now) because the DHT doesn't tell as more than addresses of peers. In theory,
:we could use a HTTP HEAD request to gather information like filename and
:filesize to fabricate a search result.

I think "ALOC" values contain enough to fake a query hit if needed.

Raphael

------------------------------

------------------------------------------------------------------------------

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 28, Issue 2
*************************************************

gtk-gnutella-devel Digest, Vol 28, Issue 1

2009-04-01T14:54:52Z

Ach so! So that's what that meant. My fault for not RTFM before starting the
translation.

I will correct all those instances and post again when I update the PO
file on my server.

Thanks for pointing out the error.
--
Larry Alex?nder Nieves Colmen?rez <lanieves@...>
El Liberal Venezolano http://liberal-venezolano.net/blog/
GPG Public Key: 0x1525843C
Key Fingerprint = 76D0 2DA1 ADA8 11EF 661B FEE2 923C 050F 1525 843C
gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 0x1525843C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature

------------------------------

Message: 2
Date: Fri, 27 Mar 2009 00:25:32 +0100
From: Larry Nieves <lanieves@...>
Subject: Re: [gtk-gnutella-devel] Update Spanish Translation
To: gtk-gnutella-devel@...
Message-ID: <20090326232532.GD4408@...>
Content-Type: text/plain; charset="utf-8"

Hi guys,

I updated the Spanish translation for gtk-gnutella. It is available, as
before, here:

http://cronicaslinuxeras.com/media/blogs/sw/translation/gtk-gnutella-es-r16210.po.bz2
urn:bitprint:IKHOFEHAFUGZNZTF5EKLWUII2LRMFKQ7.YXNNKSWFYXOFGH67FYDVHC75FKR764SR327SCNA

I hope this one does make it into the release.

On Tue, Mar 24, 2009 at 08:52:30PM +0100, Christian Biere wrote:

> Larry Nieves wrote:
> > Make that:
> >
> > urn:bitprint:VJQ3EIWL562AJEHPETK55W7QWYSA2FDR.2PL5LDTOONZMQMK4552ZAL2UXQS3PMDNFV6K2OY
> >
> > I found a couple of errors and updated.
>
> I found some mistakes, too. If you translate something like "Bitzi|Underrated", you must
> strip the "Bitzi|" in the translated string. The "pipe symbol" is a special character
> in this context. This is also documented in the I18N guide:
>
> https://gtk-gnutella.svn.sourceforge.net/svnroot/gtk-gnutella/trunk/gtk-gnutella/doc/devguide/I18N
>
> Could you correct this, please? Thanks.
>
> --
> Christian
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> gtk-gnutella-devel mailing list
> gtk-gnutella-devel@...
> https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

--
Larry Alex?nder Nieves Colmen?rez <lanieves@...>
El Liberal Venezolano http://liberal-venezolano.net/blog/
GPG Public Key: 0x1525843C
Key Fingerprint = 76D0 2DA1 ADA8 11EF 661B FEE2 923C 050F 1525 843C
gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 0x1525843C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature

------------------------------

Message: 3
Date: Fri, 27 Mar 2009 08:24:16 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Update Spanish Translation
To: gtk-gnutella-devel@...
Message-ID: <gqi2fg$j3v$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Larry Nieves <lanieves@...> from ml.softs.gtk-gnutella.devel:
:http://cronicaslinuxeras.com/media/blogs/sw/translation/gtk-gnutella-es-r16210.po.bz2
:urn:bitprint:IKHOFEHAFUGZNZTF5EKLWUII2LRMFKQ7.YXNNKSWFYXOFGH67FYDVHC75FKR764SR327SCNA

Thanks, committed to SVN.

Raphael

------------------------------

Message: 4
Date: Mon, 30 Mar 2009 18:40:27 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Update Spanish Translation
To: gtk-gnutella-devel@...
Message-ID: <20090330164027.GA5788@...>
Content-Type: text/plain; charset=utf-8

Larry Nieves wrote:
> I updated the Spanish translation for gtk-gnutella.

Thanks for your translation efforts. If you'd like, you could translate the homepage or parts
thereof, too. You'll find some helpful information regarding this process here:

https://gtk-gnutella.svn.sourceforge.net/svnroot/gtk-gnutella/trunk/gtk-gnutella/doc/devguide/HOMEPAGE

--
Christian

------------------------------

Message: 5
Date: Wed, 1 Apr 2009 15:41:30 +0200
From: Alexander Nicolaysen S?rnes <alex@...>
Subject: [gtk-gnutella-devel] Updated Norwegian Bokm?l translation
To: gtk-gnutella-devel@...
Message-ID: <200904011541.31434.alex@...>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

Here is yet another update for the Norwegian Bokm?l translation. It contains a
few untranslated strings, but I wanted to make sure it makes it into the
forthcoming release.

http://www.thehandofagony.com/alex/oversetting/gtk-gnutella/gtk-gnutella-nb-
svn-20090328.tar.bz2

Alexander N. S?rnes

------------------------------

Message: 6
Date: Wed, 1 Apr 2009 23:32:15 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Updated Norwegian Bokm?l translation
To: gtk-gnutella-devel@...
Message-ID: <20090401213215.GA18092@...>
Content-Type: text/plain; charset=utf-8

Hi,

Alexander Nicolaysen S?rnes wrote:
> Here is yet another update for the Norwegian Bokm?l translation. It contains a
> few untranslated strings, but I wanted to make sure it makes it into the
> forthcoming release.
>
> http://www.thehandofagony.com/alex/oversetting/gtk-gnutella/gtk-gnutella-nb-
> svn-20090328.tar.bz2

"unfortunately", 0.96.6 has already been released. If I remember correctly,
a specific date wasn't announced in advance, so you couldn't have known.
Maybe - just maybe - there will soon be a next release with some minor
fixes/enhancements that didn't make it into the current release. So you
still have time to translate those last strings, if you'd like.

In any case, thanks for your sustained translations!

--
Christian

------------------------------

Message: 7
Date: Wed, 01 Apr 2009 23:54:23 +0200
From: Raphael Manfredi <Raphael_Manfredi@...>
Subject: [gtk-gnutella-devel] Version 0.96.6 stable has been released
To: gtk-gnutella-users@...,
gtk-gnutella-devel@...
Message-ID: <21977.1238622863@...>

Dear Gnutella fans,

Version 0.96.6 stable has been released on sourceforge. You may get it at:

http://downloads.sourceforge.net/gtk-gnutella/gtk-gnutella-0.96.6.tar.bz2

You can also download this release from Gnutella using this link:

magnet:?xt=urn:sha1:GGKBP2G6CBFTHEJ6BCQKV3EMB4RKMEU5&dn=gtk-gnutella-0.96.6.tar.bz2

IMPORTANT: Please note that the previous stable release 0.96.5 expires on
April 1st, in a few days. Consider upgrading to the newest release by
compiling the program yourself to avoid any inconvenience.

Here are the changes since 0.96.6, as listed in the ChangeLog:

# v 0.96.6 2009-03-29 [stable]

Bug Fixes:

- #1932909 "columns in search window do not scale properly".
- Fixed improper HTTP chunking when outputing chunks larger than 64 KiB.
- #2628899 "tries to download from my old self after IP changes".
- Was not always resuming the interrupted SHA-1 computation of a finished file
when servent was closed in the middle of processing.
- Fixed bad range checking test in the download part.
- Was not paying attention to the "give_server_hostname" property and instead
sent "HNAME" GGEP extensions in query hits provided a non-empty name was
defined as the "server_hostname".
- Fixed improper upload slot counting which introduced race conditions,
sometimes leading to having more slots used than the configured maximum
(in addition to the "quick" upload slots).
- Prevent occasional crashes at shutdown time, during subsystem cleanups.
- Fixed corner cases where we could lose a server hostname and downright bug
where we discarded the hostname after a DNS lookup if the subsequent
connection attempt did not succeed.

Improvements:
- Refuse to share certain directories: /, $HOME, $GTK_GNUTELLA_DIR, and
the incomplete and corrupted directories.
- Downloads GUI: added checkboxes to invert the select/filter patterns.
- Downloads GUI: added "Modified" column and detail showing the timestamp of
the last file modification.
- Optional beautification operations on filenames: strip leading "-", remove
consecutive "_" and prevent "_" surrounding punctuation characters.
- Fixed significant performance issue in the Gtk+ 1.2 front-end: update of
upload statistics was O(n) but is now O(1).
- Background TTH file verification now lights an icon in the GUI.
- Show TTH tree depth in the download "Details" pane.
- Update the bitzi metadata info box when a query finishes, so that it is
not required to click on the result again after requesting bitzi data.
- Added MIME type column for search results.
- Added "Last Request" and "Last Upload" columns to the Upload History.
- Almost complete DHT support (missing only publishing of data), but code
needs to be explicitly enabled by setting "enable_dht" to TRUE. The DHT
knows how to look for alt-locs for files and push-proxies for firewalled
hosts, and will store local data for others to query.
- New shell commands "stats", "download", "echo".
- It is now possible to rename files being downloaded (through GTK2 or shell,
no support in GTK1).
- Added more filename extensions to the built-in search filters.
- Switch resources after getting an HTTP error if the connection is kept alive
and the error permits follow-ups (non-busy conditions).
- Improved ability to switch resources after file completion by ignoring
trailing swarming data, to keep the connection alive.
- Bitzi tickets are refreshed when explicitely requested, avoiding reuse
of stale metadata
- Completed files are displayed during hash verification.
- Only propagate good alt-locs for files we are downloading, i.e. addresses
of hosts which we know to be serving that file because we contacted them.
- Many new statistics counters.
- Allow scheduling of special downloads without considering per-host limits,
as these are of a much shorter duration (THEX and browse host requests).
- Always seed completed files, regardless of their size (no PFSP minimum as
with partial files), when their SHA-1 has been verified.
- Incorrectly encoded Bitzi metadata is translated to Unicode.
- Browse-host responses are sorted alphanumerically on relative pathnames to
allow users to relate files together if they don't understand GGEP "PATH".
- Improved routing of PUSH messages by also looking whether targetted hosts
happen to be one of our immediate neighbours.
- Updated Norwegian Bokmal and Spanish translations.

Under the hood:

- Parse legacy Shareaza THEX URIs "urn:tree:tiger/:" (extra "/" here).
- Handle non-standard X-Thex-URI headers if peer provides a valid
X-Content-URN header (Shareaza 2.1.0.0).
- Also attempt to give priority to the last "pfsp_last_chunk" bytes of
downloaded files, since that can contain important indexing information to
enable pre-view of partial video files.
- More MIME types known (derived from file extensions).
- Can now download THEX data at a tree depth of 11 for files larger than 1 GiB.
- Can download sub-optimal THEX data, as non-optimal data is better than none,
but keeps looking for THEX data at the optimal tree depth nonetheless.
- Reimplemented scanning of shared directories as a background task so that
the process (not just the GUI) is fully responsive during the whole scan.
- Let the background task scheduler compute the proper amount of ticks to
use for each task.
- Upload statistics now record the file's SHA-1, so that we can consolidate
partial file sharing with library sharing statistics, with the filename
being forced to the library's filename.
- Avoid starting moving a completed file if there is not enough space on
the targetted file system.
- Recognize and propagate the "DHT" GGEP extension in pongs.
- Added support for "DHTIPP" GGEP extension in pings, used for DHT bootstrap.
- Added more entropy to the random number seed.
- Plugged memory leaks
- No longer send SHA-1 queries on the Gnutella network. They are now performed
through the DHT, which has the suitable topology to do so efficiently.
- Fixed UDP bandwidth computation, and removed any limit on UDP incoming.
- Updated list of hostile IP adress ranges, Geo-IP data, spam patterns and
spam samples.
- Property loading from files was in O(n*n), made it O(n).
- Now detect property files being blindly copied over from another
gtk-gnutella's config directory and reset properties whose value needs to
be unique.
- The GUID and the KUID (Kademlia ID, the DHT node ID) were made sticky.
- Optimization of QRP lookups in tables ranging from 16k to 2M slots.
- Limit amount of hits to 10 per query hit packet, as LimeWire chokes otherwise.
- Limit amount of alt-locs in hits to 10 or LimeWire chokes.
- Keep connection alive when reporting an HTTP error to allow remote resource
switching if necessary.
- Emit and parse new X-Downloaded header, apparently introduced by LimeWire.
- Added parsing of X-FW-Node-Info headers to grab push-proxies from firewalled
hosts, as well as gather the proper GUID and host address/port.
- Emit X-FW-Node-Info if node is firewalled but continue to list our
push-proxies in the standard X-Push-Proxies header.
- Avoid endless aggressive chunk splitting during swarming.
- Proper parsing of comma-separated values in Accept and other Accept-Encoding
HTTP headers.
- Reject UDP packets from unspecified addresses.
- Drain more data out of the UDP receive buffer to prevent it from filling up.
- Strip at most 5 trailing characters from words when building the QRP table,
thereby inserting less radices and making the table more sparse.
- Removed workarounds for dealing with broken 0.96.2 nodes and earlier 0.95.x.
- Extended syntax for push:// exact sources in magnets to be able to supply
all the known push-proxies, even if that is an empty set. Since downloads
are persisted as magnets, this also allows keeping all the previously
known push-proxies accross sessions.
- Upgraded PARQ to version 1.1 (mostly specification cleanups).
- Added additional anti-hammering for cases where many files on the same
server are queued and gtk-gnutella is configured to launch more than 1
connection per IP. Connection attempts to the same server are now limited
to 5 per minute.

Limitations:

- DHT code is still experimental, although functional: configuration of
parameters can only be done through the shell, and there is no support
for publishing yet.

Enjoy!

Raphael

------------------------------

------------------------------------------------------------------------------

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 28, Issue 1
*************************************************

gtk-gnutella-devel Digest, Vol 27, Issue 5

2009-03-24T12:52:00Z

> Matthew Lye wrote:
>> On 18-Mar-09, at 4:41 PM, Christian Biere wrote:
>>> Could you pin-point at what part of Configure the crashes occur?
>
>> try.c: In function ?main?:
>> try.c:14: warning: implicit declaration of function ?closefrom?
>> collect2: ld terminated with signal 6 [Abort trap]
>> Undefined symbols:
>> "_closefrom", referenced from:
>> _main in cc3gEU9T.o
>> terminate called after throwing an instance of 'char const*'
>> terminate called recursively
>
> The crash itself is probably in bug in ld. According to the
> great oracle, likely a bug in the version of binutils used by
> your system.

There's an oracle? I knew mystery cults proliferated in the IT world,
but I thought they were mainly for system administrators and Tier 1
types.

It looks like OS X has an Apple-developed ld (@(#)PROGRAM:ld
PROJECT:ld64-77), part of the Darwin project. Hasn't had a change
logged since 2007.

The linker problem should only be a nuisance for people who've enabled
the bug reporting system included in the Xcode bundle. There's
probably a way to disable it per session, somewhere off in
Onlinedokumentistan; I'll let you know if it turns up.

------------------------------

Message: 3
Date: Fri, 20 Mar 2009 01:20:46 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] feeling bitter about symbolic links
& build errata
To: gtk-gnutella-devel@...
Message-ID: <20090320002046.GB17434@...>
Content-Type: text/plain; charset=utf-8

Matthew Lye wrote:
> There's an oracle?

Maybe. Just google it.

> The linker problem should only be a nuisance for people who've enabled
> the bug reporting system included in the Xcode bundle. There's
> probably a way to disable it per session, somewhere off in
> Onlinedokumentistan; I'll let you know if it turns up.

I take it the modifications to Configure didn't make any difference?

--
Christian

------------------------------

Message: 4
Date: Fri, 20 Mar 2009 00:33:26 -0400
From: Matthew Lye <mlye@...>
Subject: Re: [gtk-gnutella-devel] feeling bitter about symbolic links
& build errata
To: gtk-gnutella-devel@...
Message-ID: <76F7743B-0FD2-4ED2-BDDC-76C2204A4DF2@...>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

On 19-Mar-09, at 8:20 PM, Christian Biere wrote:

> Matthew Lye wrote:
>> There's an oracle?
>
> Maybe. Just google it.
>
>> The linker problem should only be a nuisance for people who've
>> enabled
>> the bug reporting system included in the Xcode bundle. There's
>> probably a way to disable it per session, somewhere off in
>> Onlinedokumentistan; I'll let you know if it turns up.
>
> I take it the modifications to Configure didn't make any difference?

No, sorry.

The abort-signaling errors seem to occur only when a function is
assumed to be being implicitly declared. That is, when 'invent.h' is
not found the linker fails gracefully even though getinvent() is being
implicitly (of course) declared. Similarly, the test for
posix_fadvise() fails gracefully because none of the identifiers
(such as POSIX_FADV_NORMAL) in the code are declared, an obvious
error. However, the test for a function NOT declared in an existing
header file fails ungracefully, producing an abort signal.

There is a cc flag in the Darwin version of gcc, '-Werror-implicit-
function-declaration', which causes all implicit declarations to be
treated as errors rather than warnings. Unfortunately one must then
include 'stdlib.h' to use exit, but this seems to only be once, in
'try.c'.

Treating implicit function declarations as errors seems to solve every
incidence of non-graceful termination, pre-empting it with graceful
termination, except for one. When the use of the locale_charset()
function left undeclared by the (existing) header file 'libcharset.h'
is tested, the implicit declaration goes unnoticed. I'm not sure why.

------------------------------

Message: 5
Date: Fri, 20 Mar 2009 09:26:42 -0500
From: Bill Pringlemeir <bpringle@...>
Subject: Re: [gtk-gnutella-devel] weird sigabrt crashes with ld in
config testing
To: Matthew Lye <mlye@...>
Cc: gtk-gnutella-devel@...
Message-ID: <871vss46e5.fsf@...>
Content-Type: text/plain; charset=us-ascii

On 15 Mar 2009, mlye@... wrote:

> I am, by the way, getting some weird crash notifications from ld when
> the configure (build) script is running, between 2-4 per run. Is a
> behavior unique to GNU-ld being assumed maybe? This behavior is new.
> It's been a while since I built GTKG, however, so it could be a change
> in the system rather than a change in your script; I'm not sure I
> would know.
>
> Process: ld [27402]
>
> Thread 0 Crashed:

> 4 libstdc++.6.dylib 0x001529a4 std::terminate() + 68
> 5 libstdc++.6.dylib 0x00152c68 __cxa_rethrow + 128
> 6 libstdc++.6.dylib 0x00154d88
> __gnu_cxx::__verbose_terminate_handler() + 244
> 7 libstdc++.6.dylib 0x00152940 __gxx_personality_v0 +
> 1240
> 8 libstdc++.6.dylib 0x001529a4 std::terminate() + 68
> 9 libstdc++.6.dylib 0x00152be4 __cxa_throw + 124
> 10 ld 0x00011294 0x1000 + 66196

Apple seems to have shipped you the gold linker. It is buggy. Can
you get the regular binutils linker and not use the gold one? The
regular ld is written in 'C'. From your stack trace, ld is throwing
an un-caught exception. Also, gold was most tested/developed on the
x86. Support for the PPC is perhaps a bit behind.

In any case, it is not a gtk-gnutella problem at all.

fwiw,
Bill Pringlemeir.

------------------------------

Message: 6
Date: Tue, 24 Mar 2009 15:15:48 +0100
From: Larry Nieves <lanieves@...>
Subject: [gtk-gnutella-devel] Update Spanish Translation
To: gtk-gnutella-devel@...
Message-ID: <20090324141548.GB13855@...>
Content-Type: text/plain; charset="utf-8"

I think I made it before the deadline.

An updated spanish translation for gtk-gnutella is available on the
following URL. It is 99% complete, with only 3 untranslated strings,
which I could not make sense of inside my head.

http://cronicaslinuxeras.com/media/blogs/sw/translation/gtk-gnutella-es-r16210.po.bz2

aka:

urn:bitprint:OOOWZMIPMVGNX5FCSOR7MTOGM3I63CDA.RHJ6KWLGRZTSJDIJVBQYUA3GXVMLRFVK2FV7FIQ

I stripped all the source references from the po file :)
--
Larry Alex?nder Nieves Colmen?rez <lanieves@...>
El Liberal Venezolano http://liberal-venezolano.net/blog/
GPG Public Key: 0x1525843C
Key Fingerprint = 76D0 2DA1 ADA8 11EF 661B FEE2 923C 050F 1525 843C
gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 0x1525843C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature

------------------------------

Message: 7
Date: Tue, 24 Mar 2009 20:24:11 +0100
From: Larry Nieves <lanieves@...>
Subject: Re: [gtk-gnutella-devel] Update Spanish Translation
To: gtk-gnutella-devel@...
Message-ID: <20090324192411.GA31559@...>
Content-Type: text/plain; charset="utf-8"

On Tue, Mar 24, 2009 at 03:15:48PM +0100, Larry Nieves wrote:
> aka:
>
> urn:bitprint:OOOWZMIPMVGNX5FCSOR7MTOGM3I63CDA.RHJ6KWLGRZTSJDIJVBQYUA3GXVMLRFVK2FV7FIQ
>

Make that:

urn:bitprint:VJQ3EIWL562AJEHPETK55W7QWYSA2FDR.2PL5LDTOONZMQMK4552ZAL2UXQS3PMDNFV6K2OY

I found a couple of errors and updated.

--
Larry Alex?nder Nieves Colmen?rez <lanieves@...>
El Liberal Venezolano http://liberal-venezolano.net/blog/
GPG Public Key: 0x1525843C
Key Fingerprint = 76D0 2DA1 ADA8 11EF 661B FEE2 923C 050F 1525 843C
gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 0x1525843C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature

------------------------------

Message: 8
Date: Tue, 24 Mar 2009 20:52:30 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Update Spanish Translation
To: gtk-gnutella-devel@...
Message-ID: <20090324195230.GA38@...>
Content-Type: text/plain; charset=utf-8

Larry Nieves wrote:
> Make that:
>
> urn:bitprint:VJQ3EIWL562AJEHPETK55W7QWYSA2FDR.2PL5LDTOONZMQMK4552ZAL2UXQS3PMDNFV6K2OY
>
> I found a couple of errors and updated.

I found some mistakes, too. If you translate something like "Bitzi|Underrated", you must
strip the "Bitzi|" in the translated string. The "pipe symbol" is a special character
in this context. This is also documented in the I18N guide:

https://gtk-gnutella.svn.sourceforge.net/svnroot/gtk-gnutella/trunk/gtk-gnutella/doc/devguide/I18N

Could you correct this, please? Thanks.

--
Christian

------------------------------

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 27, Issue 5
*************************************************

gtk-gnutella-devel Digest, Vol 27, Issue 4

2009-03-18T22:05:18Z

> I'm suspecting there is something wrong with the push-proxy handling
> in GTKG because I'm not seeing any push-proxy request made locally.
> I cannot seem to be able to pinpoint anything wrong however, other
> than finding it strange to never get any push-proxy request when I
> am the push-proxy of so many leaves.
>
> Can anyone running lastest SVN as an ultra node run this from the
> shell:
>
> echo stats | gtk-gnutella --shell | grep ^push_proxy
>
> and let me know if you see non-zero values in the output?
>

I have one UP running since one hour ago, with 20 Leaves connected to
it, 18 of which are push-proxied by my node. So far all zeros on the
push_proxy counts statistics. Version is r16136 (I think that's
yesterday commit, if I'm not wrong).
--
Larry Alex?nder Nieves Colmen?rez <lanieves@...>
El Liberal Venezolano http://liberal-venezolano.net/blog/
GPG Public Key: 0x1525843C
Key Fingerprint = 76D0 2DA1 ADA8 11EF 661B FEE2 923C 050F 1525 843C
gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 0x1525843C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature

------------------------------

Message: 3
Date: Tue, 17 Mar 2009 22:04:44 -0400
From: Matthew Lye <mlye@...>
Subject: [gtk-gnutella-devel] feeling bitter about symbolic links &
build errata
To: gtk-gnutella-devel@...
Message-ID: <737BDD9F-5D5C-42FE-9466-3B061E229B93@...>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Heya,

1) In ./contrib/bitter, 'config.h' and the contents of the 'src'
directory are symbolic links to items in a directory that does not
exist on my computer.

2) -pipe is not being added to my cc flags the way it should be; I'm
not sure why. This seems to coincide with a 'HOLD IT, the default...'
verification (breezed through by build.sh) that does not appear if I
add it myself when running build.sh.

3) Not all instances of rm in Configure have the directory flag set.
This is needed to remove "*.dSYM" directories created by compiling/
linking tests.

4) The linker crashes appear to be an OS X 10.5.6 (possibly only on
PPC) problem, as they occur even with the pre-r15925 version of
Configure, which was last edited in September and which I believe I
would have built GTKG using at some point. They don't appear to
affect anything.

------------------------------

Message: 4
Date: Wed, 18 Mar 2009 17:31:08 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] [gtk-gnutella-users] Call for
translations
To: gtk-gnutella-devel@...
Message-ID: <20090318163107.GA9740@...>
Content-Type: text/plain; charset=utf-8

Raphael Manfredi wrote:
> Quoting Larry Nieves <lanieves@...> from ml.softs.gtk-gnutella.users:
> :Here you go. I always forget which is the correct order for diff (the
> :new file first, or the old file first), so if this patch is reversed, I
> :apologize. Anyway it's only one line that has to be modified.
>
> Thanks, committed, and all po files were updated.

Was there any point to commit this, if any translator can do exactly
this? The PO files and the POT file are inherently stale and are only
snapshots. Before starting translating or updating the translation
one should always fetch the newest sources and regenerate the POT
file.

> Note that source code location is in essence fuzzy: the source code
> changes regularily (this is why there was this --no-location switch
> in the first place).

The comments have been removed because they are always stale and
if I remember correctly not even updated/corrected. So after a
couple of updates you end up with billions of useless source
code references and the diffs become very bloated because these
exact location of comments changes all the time.

--
Christian

------------------------------

Message: 5
Date: Wed, 18 Mar 2009 17:28:49 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] [gtk-gnutella-users] Call for
translations
To: gtk-gnutella-devel@...
Message-ID: <gprb0h$2k5$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel:
:Was there any point to commit this, if any translator can do exactly
:this? The PO files and the POT file are inherently stale and are only
:snapshots. Before starting translating or updating the translation
:one should always fetch the newest sources and regenerate the POT
:file.

I want to ease the job of translaters as much as possible since the
time before the release is short.

:The comments have been removed because they are always stale and
:if I remember correctly not even updated/corrected. So after a
:couple of updates you end up with billions of useless source
:code references and the diffs become very bloated because these
:exact location of comments changes all the time.

Of course, the plan is to re-instantiate the --no-location switch before
making the release. And naturally, I do not plan to regenerate a new POT
each time there is a source commit. The current locations will have to do.
People with a proper build environment can always run:

make gtk-gnutella.pot-update
make

to regenerate the proper locations.

Raphael

------------------------------

Message: 6
Date: Wed, 18 Mar 2009 21:41:44 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] feeling bitter about symbolic links
& build errata
To: gtk-gnutella-devel@...
Message-ID: <20090318204144.GA13668@...>
Content-Type: text/plain; charset=utf-8

Matthew Lye wrote:

> Heya,
>
> 1) In ./contrib/bitter, 'config.h' and the contents of the 'src'
> directory are symbolic links to items in a directory that does not
> exist on my computer.
>
> 2) -pipe is not being added to my cc flags the way it should be; I'm
> not sure why. This seems to coincide with a 'HOLD IT, the default...'
> verification (breezed through by build.sh) that does not appear if I
> add it myself when running build.sh.

These two issues should be corrected now.

> 3) Not all instances of rm in Configure have the directory flag set.
> This is needed to remove "*.dSYM" directories created by compiling/
> linking tests.

This should be fixed, too. If you still notice any remaining garbage,
let me know.

> 4) The linker crashes appear to be an OS X 10.5.6 (possibly only on
> PPC) problem, as they occur even with the pre-r15925 version of
> Configure, which was last edited in September and which I believe I
> would have built GTKG using at some point. They don't appear to
> affect anything.

Could you pin-point at what part of Configure the crashes occur?

--
Christian

------------------------------

Message: 7
Date: Thu, 19 Mar 2009 01:04:27 -0400
From: Matthew Lye <mlye@...>
Subject: Re: [gtk-gnutella-devel] feeling bitter about symbolic links
& build errata
To: gtk-gnutella-devel@...
Message-ID: <4A7CACD2-9020-4498-BF80-D33598C9A244@...>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
delsp=yes

On 18-Mar-09, at 4:41 PM, Christian Biere wrote:

>
> Could you pin-point at what part of Configure the crashes occur?

Basically what's been happening is that I've been being notified in
the GUI that crash reports have been logged (so I can send the to
Apple if needed). Either the logging system or more likely the
notification system is a lot sluggy ? it doesn't use the regular
windows manager or some such technical excuse above my comprehension
level ? so I only get as many notices as the general system load allows.

I noticed that feeding garbage into the ld command line provokes a
response thusly:

> ld ijfijojofi fsfkop
> sfofopko
> [23
> :57:45]
> terminate called after throwing an instance of 'char const*'
> terminate called recursively
> zsh: abort ld ijfijojofi fsfkop sfofopko

Additionally, it will provoke an error message in the GUI, just as the
failures in Configure did. So, I figure this is the sort of error
that's causing the trouble. Abort trap errors can be seen to occur
several times, with $trylink edited so that it doesn't dump stderr to /
dev/null.

I need to get to bed, so here's a cut & paste of Configure running
with cc errors intact. The problem areas will with luck make instant
and total sense to you.

# # # # #

~/prj/gtk-
gnutella
>
buildgtk
[0
:55:30]
First let's make sure your kit is complete. Checking...
Locating common programs...
Checking compatibility between /bin/echo and builtin echo (if any)...
Symbolic links are supported.
Checking how to test for symbolic links...
You can test for symbolic links with 'test -h'.
Good, your tr supports [:lower:] and [:upper:] to convert case.
Using [:upper:] and [:lower:] to convert case.
Operating system name? [darwin]
Operating system version? [9.6.0]
Enable remote control service [n]
Run without any GUI interface [n]
Use which GTK toolkit (1 or 2) [1]
Do you expect to run these scripts and binaries on multiple machines?
[n]
Installation prefix to use? (~name ok) [/usr/local]
AFS does not seem to be running...
Pathname where the public executables will reside? (~name ok)
[/usr/local/bin]
System manual is in /usr/local/man.
Where do the manual pages (source) go? (~name ok)
[/usr/local/share/man/man1]
Pathname where the private library files will reside? (~name ok)
[/usr/local/share/gtk-gnutella]
Use which C compiler? [cc]
Checking for GNU cc in disguise and/or its version number...
Now, how can we feed standard input to your C preprocessor...
Directories to use for library searches? [/usr/lib /usr/local/lib]
What optimizer/debugger flag should be used? [-O2 -g]
Any additional cc flags?
[-W -Wall -Wformat=2 -Wshadow -mcpu=7450 -O2 -ggdb3 -Wno-shadow -pipe]
Let me guess what the preprocessor flags are...
Any additional ld flags (NOT including libraries)? [none]
Checking your choice of C compiler and flags for coherency...
Computing filename position in cpp output for #include directives...
<libintl.h> found.
You have NLS support.
Shall I enable NLS [n]
<unistd.h> found.
<sys/file.h> defines the *_OK access constants.
<stdlib.h> found.
Checking whether your compiler can handle __attribute__ ...
try.c: In function ?main?:
try.c:14: warning: implicit declaration of function ?closefrom?
collect2: ld terminated with signal 6 [Abort trap]
Undefined symbols:
"_closefrom", referenced from:
_main in cc3gEU9T.o
terminate called after throwing an instance of 'char const*'
terminate called recursively
Checking to see if your C compiler knows about "const"...
Checking how we can gather information about dbus...
You've don't seem to have dbus installed?
try.c:2:21: error: stropts.h: No such file or directory
try.c:3:25: error: sys/devpoll.h: No such file or directory
try.c: In function ?main?:
try.c:7: error: storage size of ?dvp? isn?t known
try.c:16: error: ?POLLREMOVE? undeclared (first use in this function)
try.c:16: error: (Each undeclared identifier is reported only once
try.c:16: error: for each function it appears in.)
try.c:21: warning: implicit declaration of function ?ioctl?
try.c:21: error: ?DP_POLL? undeclared (first use in this function)
try.c:7: warning: unused variable ?dvp?
<dirent.h> found.
try.c:2:23: error: sys/epoll.h: No such file or directory
try.c: In function ?main?:
try.c:5: error: storage size of ?ev? isn?t known
try.c:7: warning: implicit declaration of function ?epoll_create?
try.c:8: error: ?EPOLLOUT? undeclared (first use in this function)
try.c:8: error: (Each undeclared identifier is reported only once
try.c:8: error: for each function it appears in.)
try.c:9: error: ?EPOLLPRI? undeclared (first use in this function)
try.c:10: error: ?EPOLLERR? undeclared (first use in this function)
try.c:11: error: ?EPOLLHUP? undeclared (first use in this function)
try.c:12: error: ?EPOLLET? undeclared (first use in this function)
try.c:17: warning: implicit declaration of function ?epoll_ctl?
try.c:17: error: ?EPOLL_CTL_ADD? undeclared (first use in this function)
try.c:18: error: ?EPOLL_CTL_MOD? undeclared (first use in this function)
try.c:19: error: ?EPOLL_CTL_DEL? undeclared (first use in this function)
try.c:20: warning: implicit declaration of function ?epoll_wait?
try.c:5: warning: unused variable ?ev?
Shall I enable "fast assertions" [y]
<arpa/inet.h> found.
<netdb.h> found.
Checking whether getaddrinfo() can be used ...
Checking whether geteuid() is available ...
<net/if.h> found.
Checking whether getifaddrs() is available ...
try.c:1:20: error: invent.h: No such file or directory
try.c: In function ?main?:
try.c:4: error: nested functions are disabled, use -fnested-functions
to re-enable
try.c:4: error: syntax error before ?*? token
try.c:5: error: ?ret? undeclared (first use in this function)
try.c:5: error: (Each undeclared identifier is reported only once
try.c:5: error: for each function it appears in.)
try.c:5: warning: implicit declaration of function ?getinvent?
What is the file extension used for shared libraries? [dylib]
Checking for optional libraries...
Which libraries to use? [-lz -lresolv -liconv -lm -lintl]
Checking for GNU C Library...
Shall I use nm to extract C symbols from the libraries? [n]
getdtablesize() found.
Checking whether getuid() is available ...
Checking how we can gather information about GNU TLS...
Enable GNU TLS support [y]
<netinet/in.h> found.
<netinet/ip.h> found.
Checking for IP TOS (Type of Service) support...
Checking whether IPv6 can be used ...
Checking whether the member "udata" of "struct kevent" is an integer ...
try.c: In function ?main?:
try.c:7: error: invalid operands to binary |
Checking whether kqueue() is available ...
Checking how we can gather information about libxml2...
<libcharset.h> found.
collect2: ld terminated with signal 6 [Abort trap]
Undefined symbols:
"_locale_charset", referenced from:
_main in ccDRJLA9.o
terminate called after throwing an instance of 'char const*'
terminate called recursively
<sys/stat.h> found.
<sys/mman.h> found.
try.c: In function ?main?:
try.c:9: warning: implicit declaration of function ?memalign?
try.c:9: warning: assignment makes pointer from integer without a cast
collect2: ld terminated with signal 6 [Abort trap]
Undefined symbols:
"_memalign", referenced from:
_main in ccr3S5te.o
terminate called after throwing an instance of 'char const*'
terminate called recursively
Checking whether "struct msghdr" has a member "msg_flags"...
<sys/file.h> defines the O_* constants...
and you have the 3 argument form of open().
<poll.h> found.
<sys/poll.h> found.
Checking whether posix_fadvise() is available ...
try.c: In function ?main?:
try.c:10: error: ?POSIX_FADV_NORMAL? undeclared (first use in this
function)
try.c:10: error: (Each undeclared identifier is reported only once
try.c:10: error: for each function it appears in.)
try.c:11: error: ?POSIX_FADV_RANDOM? undeclared (first use in this
function)
try.c:12: error: ?POSIX_FADV_SEQUENTIAL? undeclared (first use in this
function)
try.c:13: error: ?POSIX_FADV_WILLNEED? undeclared (first use in this
function)
try.c:14: error: ?POSIX_FADV_DONTNEED? undeclared (first use in this
function)
try.c:14: error: ?POSIX_FADV_NOREUSE? undeclared (first use in this
function)
try.c:16: warning: implicit declaration of function ?posix_fadvise?
Checking whether posix_memalign() is available ...
try.c: In function ?main?:
try.c:10: warning: implicit declaration of function ?posix_memalign?
collect2: ld terminated with signal 6 [Abort trap]
Undefined symbols:
"_posix_memalign", referenced from:
_main in ccJDACbl.o
terminate called after throwing an instance of 'char const*'
terminate called recursively
try.c: In function ?main?:
try.c:13: warning: implicit declaration of function ?preadv?
collect2: ld terminated with signal 6 [Abort trap]
Undefined symbols:
"_preadv", referenced from:
_main in ccEYHm76.o
terminate called after throwing an instance of 'char const*'
terminate called recursively
try.c: In function ?main?:
try.c:13: warning: implicit declaration of function ?pwritev?
collect2: ld terminated with signal 6 [Abort trap]
Undefined symbols:
"_pwritev", referenced from:
_main in ccoZ6KMG.o
terminate called after throwing an instance of 'char const*'
terminate called recursively
<sys/resource.h> found.
Checking whether SA_INTERRUPT is available in <signal.h>...
try.c: In function ?main?:
try.c:5: error: ?SA_INTERRUPT? undeclared (first use in this function)
try.c:5: error: (Each undeclared identifier is reported only once
try.c:5: error: for each function it appears in.)
try.c:2:26: error: sys/sendfile.h: No such file or directory
try.c: In function ?main?:
try.c:9: warning: implicit declaration of function ?sendfile?
try.c:2:26: error: sys/sendfile.h: No such file or directory
try.c: In function ?main?:
try.c:9: warning: implicit declaration of function ?sendfile?
try.c: In function ?main?:
try.c:12: warning: implicit declaration of function ?setproctitle?
collect2: ld terminated with signal 6 [Abort trap]
Undefined symbols:
"_setproctitle", referenced from:
_main in ccXmJplw.o
terminate called after throwing an instance of 'char const*'
terminate called recursively
POSIX sigsetjmp found.
Checking whether getaddrinfo() can be used ...
<sys/mount.h> found.
<sys/param.h> found.
<sys/vfs.h> NOT found.
<sys/times.h> found.
times() found.
What type is returned by times() on this system? [clock_t]
Figuring out host name...
Your host name appears to be "theimac.local". Right? [y]
uname() found.
Checking to see if your C compiler knows about "volatile"...
try.c: In function ?func?:
try.c:10: warning: ?ap? is used uninitialized in this function
Checking whether we need flags for large file support...
Checking alignment constraints...
Doubles must be aligned on a how-many-byte boundary? [4]
Checking to see how your cpp does stuff like catenate tokens...
You have void (*signal())() instead of int.
Figuring out the flag used by open() for non-blocking I/O...
Let's see what value errno gets from read() on a O_NONBLOCK file...
Compiling for GTK 1: we'll use 'glade'.
Checking how we can gather information about GLib...
Checking how we can gather information about GTK+...
Figuring out my version number...
Looking for a BSD-compatible install program...
Which install program shall I use? (~name ok) [/usr/bin/install]
Ok, let's see how we can create nested directories...
Which memory models are supported? [none]
Checking if your /usr/bin/make program sets $(MAKE)...
Checking how to generate makefile dependencies on your machine...
Name of program to make makefile dependencies? (~name ok)
[/Users/mlye/prj/gtk-gnutella/mkdep]
Let's see whether your /usr/local/bin/msgmerge supports the --update
flag...
Checking out function prototypes...
Checking how to generate random libraries on your machine...
Checking to see how well your C compiler groks the void type...
Which compiler compiler (yacc or bison -y) shall I use? [yacc]
Any additional yacc flags? [none]
<sys/file.h> found.
We'll be including <sys/file.h>.
<fcntl.h> found.
We don't need to include <fcntl.h> if we include <sys/file.h>.
<ifaddrs.h> found.
<inttypes.h> found.
<invent.h> NOT found.
<langinfo.h> found.
<math.h> found.
<pwd.h> found.
<regex.h> found.
<stdarg.h> found.
<varargs.h> found.
We'll include <stdarg.h> to get va_dcl definition.
Using <string.h> instead of <strings.h>.
<sys/sendfile.h> NOT found.
<sys/socket.h> found.
<sys/statvfs.h> found.
<sys/sysctl.h> found.
Testing to see if we should include <time.h>, <sys/time.h> or both.
We'll include <sys/time.h>.
<sys/types.h> found.
<sys/un.h> found.
<sys/utsname.h> found.
<iconv.h> found.
<zlib.h> found.
Checking whether -mieee should be used...
cc1: error: invalid option ?ieee?
Checking whether -pipe should be used...

Feature Summary (Version 0.96.6u):
-------------------------------------------------
GLib version : glib-1.x
GUI front-end : GTK1
GNU TLS support : yes
IPv6 support : yes
NLS (Native Language Support) : no
Fast assertions : yes
DBus support (experimental) : no
Remote Shell Interface (deprecated): no
-------------------------------------------------
Creating config.sh...
Doing variable substitutions on .SH files...
Extracting Makefile (with variable substitutions)
Extracting config.h (with variable substitutions)
Extracting extra_files/Makefile (with variable substitutions)
Extracting extra_files/el/Makefile (with variable substitutions)
Extracting extra_files/en/Makefile (with variable substitutions)
Extracting extra_files/ja/Makefile (with variable substitutions)
Extracting gtk-gnutella.spec (with variable substitutions)
Extracting install (with variable substitutions)
Extracting pixmaps/Makefile (with variable substitutions)
Extracting po/Makefile (with variable substitutions)
Extracting src/Makefile (with variable substitutions)
Extracting src/core/Makefile (with variable substitutions)
Extracting src/dht/Makefile (with variable substitutions)
Extracting src/if/Makefile (with variable substitutions)
Extracting src/if/bridge/Makefile (with variable substitutions)
Extracting src/lib/Makefile (with variable substitutions)
Extracting src/sdbm/Makefile (with variable substitutions)
Extracting src/shell/Makefile (with variable substitutions)
Extracting src/ui/Makefile (with variable substitutions)
Extracting src/ui/gtk/Makefile (with variable substitutions)
Extracting src/ui/gtk/gtk1/Makefile (with variable substitutions)
Extracting src/ui/gtk/gtk2/Makefile (with variable substitutions)
Run /usr/bin/make depend now? [y]

------------------------------

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 27, Issue 4
*************************************************

gtk-gnutella-devel Digest, Vol 27, Issue 3

2009-03-15T16:56:36Z

gtk-gnutella-devel Digest, Vol 27, Issue 2

2009-03-10T13:17:18Z

> Hi everyone,
>
> A short message to let you know that we're nearing release time. The current
> version (0.96.5) will expire on April 1st.
>
> There has been numerous changes in SVN in the last two weeks, and I would
> appreciate if you could all download the latest SVN version (at least r16089)
> and let me know whether you experience problems with it. Make sure to compile
> with -O0 and -g, so that any core dump can be examined easily.
>
> If you haven't tried out the enabling of the DHT, you can do so by typing:
>
> $ echo set enable_dht TRUE | gtk-gnutella --shell
>

Could you please explain what DHT is with respect to gtkg? I'm only
familiar with the acronym from BitTorrent where it refers to the
distributed hash tracker for decentralised trackers (IIRC).

--
Alex, homepage: http://www.bennee.com/~alex/
Hate the sin and love the sinner.
-- Mahatma Gandhi

------------------------------

Message: 4
Date: Sun, 8 Mar 2009 21:49:10 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Nearing release time
To: gtk-gnutella-devel@...
Message-ID: <gp1egm$fcf$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Alex <alex@...> from ml.softs.gtk-gnutella.devel:
:Could you please explain what DHT is with respect to gtkg? I'm only
:familiar with the acronym from BitTorrent where it refers to the
:distributed hash tracker for decentralised trackers (IIRC).

Sure.

DHT stands for Distributed Hash Table.

In Gnutella, the DHT is used to store alt-locs (keyed by SHA-1) and
push-proxies (keyed by the GUID of the firewalled servent). This allows
one to resolve source-less magnets.

As of today, there are only two vendors supporting the DHT: LimeWire and
gtk-gnutella.

The current implementation in GTKG is not complete though, in that GTKG
can only join the DHT and query it, but it does not publish information
yet. Another limitation of the current implementation is that you need
to fully join the DHT structure to query it, whereas LimeWire has a degraded
implementation for nodes with too little bandwidth.

Due to LimeWire's poor choice of timeout constants, there is a fairly high
bandwidth price to pay to use the DHT.

The forthcoming 0.96.6 release of GTKG will not enable the DHT by default,
due to the fact that the implementation is still incomplete. However,
all the features that have been implemented are fully functional:

* THe DHT implementation is following the LimeWire specifications regarding
message structure, table architecture and protocols (Kademlia is the
underlying DHT architecture and design).

* The DHT auto-bootstraps on the network, thanks to the relatively dense
LimeWire network..

* The DHT is capable of storing data locally, if you are not firewalled,
and naturally providing this data back to the nodes who ask for it.

* The DHT code can look for ALOC (alt-locs), to find other sources
sharing a given file, and PROX (push-proxies) to be able to locate
current push-proxies for a firewalled servent, considerably raising the
chance that you can download from a firewalled (LimeWire) servent.

By default data stored in your node is kept in memory, but by setting
the property "dht_storage_in_memory" to FALSE, data will be kept on disk.
The reason this is not done by default is that the current implementation
is not handling disk-full conditions and GTKG is likely to crash if the disk
where ~/.gtk-gnutella lies becomes full.

Raphael

------------------------------

Message: 5
Date: Sun, 8 Mar 2009 22:06:20 +0100
From: Jonas Sonntag <jonas@...>
Subject: [gtk-gnutella-devel] FATAL: Assertion failure in
settings.c:738: "is_host_addr(peer)"
To: gtk-gnutella-devel@...
Message-ID: <20090308220620.6fee1ce0@...>
Content-Type: text/plain; charset=UTF-8

Hi developers,

this is from r16083 running topless in UP mode.

#0 0x000000080147998c in kill () from /lib/libc.so.6
#1 0x00000008014788f1 in abort () from /lib/libc.so.6
#2 0x0000000000532dbf in assertion_failure (data=0x5b9dd0) at
fast_assert.c:96
#3 0x00000000004d20af in settings_addr_changed (new_addr= {net = 4,
addr = {ipv6 = "?\235?P#?M\000\000\000\000\000\004\000\000", ipv4 =
1354669530}}, peer= {net = 4, addr = {ipv6 =
"\000\000\000\000#?M\000\000\000\000\000\220???", ipv4 = 0}}) at
settings.c:738
#4 0x00000000004dd129 in socket_udp_accept (s=0x8007910e0) at
sockets.c:2379
#5 0x00000000004dd2a0 in socket_udp_event (data=0x8007910e0,
unused_source=8, cond=INPUT_EVENT_R) at sockets.c:2433
#6 0x000000000053d0a8 in inputevt_timer (poll_ctx=0x7e85a0) at
inputevt.c:714
#7 0x000000000053d4cc in dispatch_poll (unused_source=0x816580,
unused_cond=G_IO_IN, udata=0x7e85a0) at inputevt.c:770
#8 0x0000000800a09388 in g_main_context_dispatch ()
from /usr/local/lib/libglib-2.0.so.0
#9 0x0000000800a0b09c in g_main_context_acquire ()
from /usr/local/lib/libglib-2.0.so.0
#10 0x0000000800a0b435 in g_main_loop_run ()
from /usr/local/lib/libglib-2.0.so.0
#11 0x00000000004e7744 in topless_main_run () at topless.c:49
#12 0x0000000000409683 in main (argc=1, argv=0x7fffffffe820) at
main.c:1454

--
br
j.

------------------------------

Message: 6
Date: Tue, 10 Mar 2009 06:25:44 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] FATAL: Assertion failure in
settings.c:738: "is_host_addr(peer)"
To: gtk-gnutella-devel@...
Message-ID: <gp5158$9b0$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Jonas Sonntag <jonas@...> from ml.softs.gtk-gnutella.devel:
:this is from r16083 running topless in UP mode.

This has been fixed.
Another important bug was just fixed in r16095.

All: please update from SVN and test this new version.

Raphael

------------------------------

Message: 7
Date: Tue, 10 Mar 2009 15:06:18 -0500
From: "Mitch Harder (aka DontPanic)" <mmharder@...>
Subject: [gtk-gnutella-devel] GTKG SVN ebuild for Gentoo Users
To: gtk-gnutella-devel <gtk-gnutella-devel@...>
Message-ID:
<89ed0c690903101306jb887e4bkcb8387a551f5fbb2@...>
Content-Type: text/plain; charset=ISO-8859-1

For people using portage (Gentoo's package and build manager), I've
put together an ebuild to build gtk-gnutella using the source code
from the Sourceforge SVN repository:

gtk-gnutella-9999.ebuild
===============================================>
# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

inherit eutils subversion

#TODO: headless mode (but not very well tested yet, may still be too
#hardcore)
IUSE="nls dbus gnutls"

DESCRIPTION="A GTK+ Gnutella client"
# SRC_URI="mirror://sourceforge/${PN}/${P}.tar.bz2"
SRC_URI=""
ESVN_REPO_URI="http://gtk-gnutella.svn.sourceforge.net/svnroot/gtk-gnutella/trunk/gtk-gnutella"
ESVN_PROJECT="gtk-gnutella"

HOMEPAGE="http://gtk-gnutella.sourceforge.net/"

SLOT="0"
LICENSE="GPL-2"
# KEYWORDS="alpha amd64 ppc sparc x86 ~x86-fbsd"
KEYWORDS="~x86 ~amd64"

RDEPEND=">=dev-libs/libxml2-2.6.0
>=x11-libs/gtk+-2.2.1
dbus? ( >=sys-apps/dbus-0.35.2 )
gnutls? ( >=net-libs/gnutls-1.0.16 )
nls? ( >=sys-devel/gettext-0.11.5 )"
DEPEND="${RDEPEND}
dev-util/pkgconfig"

src_compile() {
# gtk-gnutella now uses a custom build script which in turn drives
# the Configure script. The options for the build script are less
# arcane, so use that for clarity.

# If compiling for testing purposes, turn debugging
CFLAGS="${CFLAGS} -O0 -g"

local myconf

if ! use nls; then
myconf="${myconf} --disable-nls"
fi

if ! use dbus; then
myconf="${myconf} --disable-dbus"
fi

if ! use gnutls; then
myconf="${myconf} --disable-gnutls"
fi

./build.sh --prefix="/usr" --gtk2 ${myconf}

emake || die "Compile failed"
}

src_install() {
dodir /usr/bin
make INSTALL_PREFIX="${D}" install || die "Install failed"
dodoc AUTHORS ChangeLog README TODO
}

------------------------------

Message: 8
Date: Tue, 10 Mar 2009 21:19:41 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] FATAL: Assertion failure in
settings.c:738: "is_host_addr(peer)"
To: gtk-gnutella-devel@...
Message-ID: <20090310201941.GA27196@...>
Content-Type: text/plain; charset=utf-8

Raphael Manfredi wrote:
> Quoting Jonas Sonntag <jonas@...> from ml.softs.gtk-gnutella.devel:
> :this is from r16083 running topless in UP mode.
>
> This has been fixed.

For the record: gtk-gnutella won't crash any longer under the same circumstances.
However, whether there's a bug in gtk-gnutella, the kernel or whether it's
perfectly legitimate that you're seeing inbound UDP packets from 0.0.0.0,
I don't know.

--
Christian

------------------------------

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 27, Issue 2
*************************************************

gtk-gnutella-devel Digest, Vol 27, Issue 1

2009-03-04T05:56:34Z

> Hi,
>
> Did you know the Government is proposing an internet censorship
> scheme that goes further than any other democracy in the world?
>
> I've just signed a petition to prevent the scheme that will make the
> internet up to 87% slower, more expensive, accidentally block up to
> one in 12 legitimate sites, will miss the vast majority of
> inappropriate content and is very easily sidestepped. The government
> of the day may add any ?unwanted? site to a secret blacklist under
> the scheme.
>
> Our Government should be doing all in its power to take Australia
> into the 21st century economy, and to protect our children. This
> proposed internet censorship does neither. Can you join me and take
> action on the net today to save the net?
>
> http://www.getup.org.au/campaign/SaveTheNet/442
>
> Thanks!

------------------------------

Message: 5
Date: Sun, 8 Feb 2009 16:53:03 +0100
From: Larry Nieves <lanieves@...>
Subject: [gtk-gnutella-devel] FATAL: Assertion failure in dbmap.c:122:
"dm->count == map_count(dm->u.m.map)"
To: gtk-gnutella-devel@...
Message-ID: <20090208155303.GG8131@...>
Content-Type: text/plain; charset=utf-8

I upgraded late last night to the latest SVN GTKG:

gtk-gnutella/0.96.6u-15953

After around 3 minutes running, the client crashes with error on the
Subject above. This is what was happening at the moment:

09-02-08 02:43:28 (MESSAGE): BOOT collected <scrubbed> from UDP IPP pong from <scrubbed>
09-02-08 02:43:29 (MESSAGE): bitzi_query_by_sha1: result already in cache
09-02-08 02:43:29 (MESSAGE): bitzi_gui_update: data 0xb7123168, size 366278394
goodness 2.100000, judgement 10, type video/x-msvideo, details 624x352, 24 fps, 1141 kbps
09-02-08 02:43:29 (MESSAGE): bitzi_query_by_sha1: result already in cache
09-02-08 02:43:29 (MESSAGE): bitzi_gui_update: data 0xb7123144, size 366287110
goodness 2.100000, judgement 10, type video/x-msvideo, details 624x352, 24 fps, 1142 kbps
FATAL: Assertion failure in dbmap.c:122: "dm->count == map_count(dm->u.m.map)"
RT created new chunk #0, now holds 0 / 16384
HSEP: Shared files changed to 40 (12173793 KiB)
CRASH (pid=21062) by SIGABRT

I tried once again and this time GTKG "survives" less than 1 minute with
identical message.

I then downgrade to r15952 and exactly the same happens after less than
40 seconds running.

I then downgraded to r15951 and this time GTKG manages to run for
almost 13 hours, but at the final stages of a download it crashes again:

09-02-08 15:23:39 (MESSAGE): DHT STORE valid security token from <scrubbed>* (LIME v0.0) [3f4c84cb2a52cb6da25aac583fc962a508f2796c] "unknown", ref=1 fw
WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
09-02-08 15:23:39 (WARNING): DHT non-routable contact address in firewalled node 127.0.0.1:0 replaced by UDP source <scrubbed>
FATAL: Assertion failure in file_object.c:309: "xfo == fo"
RT created new chunk #0, now holds 0 / 16384
HSEP: Shared files changed to 40 (12173793 KiB)
RT cycling over table, elapsed=4545, holds 6278 / 16384
RT cycling over table, elapsed=3718, holds 7961 / 16384
RT cycling over table, elapsed=1809, holds 7074 / 16384
RT created new chunk #1, now holds 6715 / 32768
RT cycling over table, elapsed=3626, holds 17306 / 32768
RT created new chunk #2, now holds 10646 / 49152
RT cycling over table, elapsed=3354, holds 20439 / 49152
RT cycling over table, elapsed=7447, holds 27148 / 49152
RT cycling over table, elapsed=6124, holds 26150 / 49152
RT cycling over table, elapsed=6583, holds 28352 / 49152
RT cycling over table, elapsed=6023, holds 29445 / 49152
CRASH (pid=23763) by SIGABRT

I don't know if this last crash is related to previous two.
--
Larry Alex?nder Nieves Colmen?rez <lanieves@...>
El Liberal Venezolano http://liberal-venezolano.net/blog/
GPG Public Key: 0x1525843C
Key Fingerprint = 76D0 2DA1 ADA8 11EF 661B FEE2 923C 050F 1525 843C
gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 0x1525843C

------------------------------

Message: 6
Date: Sun, 8 Feb 2009 17:18:12 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] FATAL: Assertion failure in
dbmap.c:122: "dm->count == map_count(dm->u.m.map)"
To: gtk-gnutella-devel@...
Message-ID: <20090208161811.GA1601@...>
Content-Type: text/plain; charset=utf-8

Larry Nieves wrote:
> I upgraded late last night to the latest SVN GTKG:
>
> gtk-gnutella/0.96.6u-15953
>
> After around 3 minutes running, the client crashes with error on the
> Subject above. This is what was happening at the moment:

> FATAL: Assertion failure in dbmap.c:122: "dm->count == map_count(dm->u.m.map)"

This has been fixed meanwhile. It was introduced yesterday (r15952) by activating
completely untested code. So you won't see it with any revisions older than that.

> I tried once again and this time GTKG "survives" less than 1 minute with
> identical message.
>
> I then downgrade to r15952 and exactly the same happens after less than
> 40 seconds running.
>
> I then downgraded to r15951 and this time GTKG manages to run for
> almost 13 hours, but at the final stages of a download it crashes again:
>
> 09-02-08 15:23:39 (MESSAGE): DHT STORE valid security token from <scrubbed>* (LIME v0.0) [3f4c84cb2a52cb6da25aac583fc962a508f2796c] "unknown", ref=1 fw
> WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
> WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
> WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
> WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
> WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
> WARNING: Assertion failure in downloads.c:4174: "!FILE_INFO_FINISHED(d->file_info)"
> 09-02-08 15:23:39 (WARNING): DHT non-routable contact address in firewalled node 127.0.0.1:0 replaced by UDP source <scrubbed>
> FATAL: Assertion failure in file_object.c:309: "xfo == fo"

I've never seen it, I suspect it was added in r15947 or later. It might have
been fixed meanwhile. Downgrade to be on the safe side.

--
Christian

------------------------------

Message: 7
Date: Wed, 4 Mar 2009 14:06:49 +0100
From: Hauke Hachmann <haxe@...>
Subject: [gtk-gnutella-devel] Build error in r16059
To: gtk-gnutella-devel@...
Message-ID: <200903041406.49623.haxe@...>
Content-Type: text/plain; charset="us-ascii"

Hi list,

when I try to build the current svn revision (r16059), I get the
following build error:

cd gtk2; make libgtk2.a
[...]
make[4]: *** No rule to make target `downloads.o', needed by
`libgtk2.a'. Stop.

Bye,
Hauke

------------------------------

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 27, Issue 1
*************************************************

gtk-gnutella-devel Digest, Vol 26, Issue 3

2008-11-29T04:00:43Z

> Quoting Meelis Roos <mroos@...> from ml.softs.gtk-gnutella.devel:
> :I have seen current SVN gtk-gnutella crashing abour weekly with UDP
> :processing problems. This time I finally got a readable backtrace and
> :crash location (by the way, I had to comment out the crash handler to
> :get sensible core dumps):
> :
> :Program terminated with signal 11, Segmentation fault.
> :#0 dht_find_bucket (id=0xbff39f9c) at routing.c:1206
> :1206 result = (val & mask) ? kb->one : kb->zero;
> :
> :So kb seems to be NULL...
>
> That's not possible unless `root' is also NULL. But otherwise kb can never
> be NULL (since we escape the inner loop as soon as `result' is NULL).
>
> However, `root' is only reset back to NULL in dht_close(). So if it is
> becoming NULL during operations, it means there is a memory corruption.

Have you considered that this code is reached even if dht_initialize()
was never called?

> I am not experiencing any problem with the DHT code here and I have very large
> uptimes (> 30 days). The only time I stop gtk-gnutella is when I need to
> upgrade... And I naturally switched the DHT code on!

Yes, but it's disabled by default for many good reasons. Also you can neither
disable or enable it during run-time because the code is widely ignorant of
the setting causing crashes when changed at run-time.

--
Christian

------------------------------

Message: 4
Date: Thu, 27 Nov 2008 20:46:20 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] crash at routing.c dht_find_bucket()
To: gtk-gnutella-devel@...
Message-ID: <ggn0us$f0l$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel:
:Have you considered that this code is reached even if dht_initialize()
:was never called?

Ouch, my fault. Of course, this is the problem. It's been fixed in r15883.

:Yes, but it's disabled by default for many good reasons. Also you can neither
:disable or enable it during run-time because the code is widely ignorant of
:the setting causing crashes when changed at run-time.

Indeed, support for switching the DHT on and off at runtime is not finished.

Raphael

------------------------------

Message: 5
Date: Sat, 29 Nov 2008 11:29:00 +0100
From: Hauke Hachmann <haxe@...>
Subject: [gtk-gnutella-devel] Build failure
To: gtk-gnutella-devel@...
Message-ID: <200811291129.00414.haxe@...>
Content-Type: text/plain; charset="utf-8"

Hi list,

I get the following build failure with latest svn r15883:

cc -c -I../.. -I.. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include ? -DCORE_SOURCES -DCURDIR=src/dht -O2 -g -momit-leaf-frame-pointer -W -Wall -Wformat=2 -Wshadow ?
routing.c
routing.c:72:21: error: publish.h: No such file or directory

Oh, and by the way, some lines above in the build output there is also a
warning:

kmsg.c: In function ?k_send_find_value_response?:
kmsg.c:626: warning: format ?%d? expects type ?int?, but argument 4 has
type ?size_t?
kmsg.c:626: warning: format ?%d? expects type ?int?, but argument 5 has
type ?size_t?

I know that this has nothing to do with the error mentioned above, I
just happened to see it when my screen stopped scrolling by. I thought
this should perhaps be (int)'ed away...

Bye,
Hauke

(PS: sorry to the list moderators for the hassle: I first tried to send
this message with a non-subscribed address in the From header.)

------------------------------

Message: 6
Date: Sat, 29 Nov 2008 11:51:11 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Build failure
To: gtk-gnutella-devel@...
Message-ID: <ggrabf$r01$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Hauke Hachmann <haxe@...> from ml.softs.gtk-gnutella.devel:
:Hi list,
:
:I get the following build failure with latest svn r15883:
:
:cc -c -I../.. -I.. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include ??
:-DCORE_SOURCES -DCURDIR=src/dht -O2 -g -momit-leaf-frame-pointer -W -Wall
:-Wformat=2 -Wshadow ??
:routing.c
:routing.c:72:21: error: publish.h: No such file or directory

Sorry, I missed it when I committed my last patch.

:Oh, and by the way, some lines above in the build output there is also a
:warning:
:
:kmsg.c: In function ???k_send_find_value_response???:
:kmsg.c:626: warning: format ???%d??? expects type ???int???, but argument 4 has
:type ???size_t???
:kmsg.c:626: warning: format ???%d??? expects type ???int???, but argument 5 has
:type ???size_t???

Thanks, fixed as well.

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 26, Issue 3
*************************************************

gtk-gnutella-devel Digest, Vol 26, Issue 2

2008-11-17T03:15:36Z

>
> I have found the gnutella_node object as well as the gnutella_socket, and I
> can get a file descriptor for that
> socket. I tried to send() an X-Alt header in ascii text (as defined in the
> huge specification) to the file descriptor and the remote host disconnected
> me (I was assuming that might be a safe header to send).
>
> Anybody know where the function in gnutella is to send a header object or do
> you just manually write to the socket's file descriptor? gtk-gnutella doesnt
> have much documentation.
>
> Regards,
> Robbie

> -------------------------------------------------------------------------
> 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

--
Alex, homepage: http://www.bennee.com/~alex/
Paradise is exactly like where you are right now ... only much, much better.
-- Laurie Anderson

------------------------------

Message: 2
Date: Tue, 11 Nov 2008 19:47:09 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Starting out with gtk-gnutella
development
To: gtk-gnutella-devel@...
Message-ID: <20081111184709.GB19972@...>
Content-Type: text/plain; charset=utf-8

Robbie wrote:
> Whats the difference between a gnutella header and a gnutella message?
> Is there any?

The gnutella header is the first 23 bytes of a gnutella message. Gnutella
headers have nothing to do with HTTP headers.

> If there is, how is http involved? Is it just used for connecting, uploading
> and downloading or is it used for everything else as well?

HTTP is only used for file transfers. The peer-to-peer procotol used by
Gnutella isn't HTTP, only the initial handshake looks remotely like HTTP.
Afterwards it's packet-based.

> Whats a safe, harmless header/message (both a header and message if theyre
> different) that I can send at any time in an existing gnutella connection,
> to a gnutella servent so that I can test my header/message sending
> abilities?

You can create custom vendor messages.

> Im going to connect with gtk-gnutella and have its source code
> send the header/message to the node.
>
> I have found the gnutella_node object as well as the gnutella_socket, and I
> can get a file descriptor for that socket.

> I tried to send() an X-Alt header in ascii text (as defined in the
> huge specification) to the file descriptor and the remote host disconnected
> me (I was assuming that might be a safe header to send).

send() isn't used at all anywhere in gtk-gnutella. That's several layers
too low. A gnutella_node is a peer-to-peer connection and no upload or
download connection. You don't send X-Alt headers to peers. If you want
to send specific alternate locations you're better of modifying
dmesh_fill_alternate() or dmesh_alternate_location().

--
Christian

------------------------------

Message: 3
Date: Tue, 11 Nov 2008 18:26:09 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Starting out with gtk-gnutella
development
To: gtk-gnutella-devel@...
Message-ID: <gfcio1$is4$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Robbie <robbiesyd@...> from ml.softs.gtk-gnutella.devel:
:Anybody know where the function in gnutella is to send a header object or do
:you just manually write to the socket's file descriptor? gtk-gnutella doesnt
:have much documentation.

What are you trying to achieve? Which "header object" do you want to send?

Raphael

------------------------------

Message: 4
Date: Tue, 11 Nov 2008 14:50:01 +0100
From: Arne Babenhauserheide <arne_bab@...>
Subject: [gtk-gnutella-devel] update: Starting gtk-gnutella
development ; was MODERATE -- robbie_syd_au@... posted to
the_gdf
To: gtk-gnutella-devel@...
Cc: robbie_syd_au@...
Message-ID: <200811111450.06614.arne_bab@...>
Content-Type: text/plain; charset="iso-8859-1"

I caught this message in the moderating queue of the_gdf, and I think it
belongs here:

-------------------------------------------------------

FROM: robbie_syd_au@...
DATE: Tue, 11 Nov 2008 11:41:09 -0000
SUBJECT: update: Starting gtk-gnutella development

Ive found the function that creates and sends a qhit
message. (im presuming theirs functions to send other
messages).

Now how do I send a header? Should I just create a string
and then send() it to the socket file descriptor raw, or
should I use the header_fmt functions? How do you send a
header made by the header_fmt functions to a connected node?

Regards, -AussieGuy

-------------------------------------------------------

PS: AussieGuy: Please register to the gtk-gnutella-devel list:
- https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel/

Best wishes,
Arne
--
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

------------------------------

Message: 5
Date: Wed, 12 Nov 2008 08:48:08 -0800 (PST)
From: Doug Bunger <dougbunger@...>
Subject: [gtk-gnutella-devel] Library or header files might be
missing.
To: gtk-gnutella-devel@...
Message-ID: <503462.33668.qm@...>
Content-Type: text/plain; charset="iso-8859-1"

Cannot compile under Fedora 8.? Packages for glib, glib-devel, glibc, glibc-devel, gtk+, and gtk+-devel are loaded.? Suggestions?

Checking how we can gather information about GLib...
You've got problems!? Do you have GLib installed?
*** WARNING:
*** Cannot compile against GLib version ''
***
Checking how we can gather information about GTK+...
You've got problems!? Do you have GTK+ installed?
*** WARNING:
*** you asked for GTK+ 2, I found
***
*** WARNING:
*** Cannot compile against Gtk+ version ''
***
<snip>
*** WHOA THERE!!! ***
??? The default value for $result on this machine was "define"!
??? Keep the default value? [y]

Feature Summary (Version 0.96.6u):
-------------------------------------------------
GLib version?????????????????????? : glib-2.x
GUI front-end????????????????????? : GTK2
GNU TLS support??????????????????? : no
IPv6 support?????????????????????? : yes
NLS (Native Language Support)????? : yes
Fast assertions??????????????????? : yes
DBus support (experimental)??????? : no
Remote Shell Interface (deprecated): no
-------------------------------------------------
ERROR: Cannot compile against GLib. Library or header files might be missing.
ERROR: Cannot compile against Gtk+. Library or header files might be missing.

-- Doug Bunger

-- dougbunger@...

--

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 6
Date: Mon, 17 Nov 2008 12:20:42 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Library or header files might be
missing.
To: gtk-gnutella-devel@...
Message-ID: <20081117112041.GB19853@...>
Content-Type: text/plain; charset=utf-8

Doug Bunger wrote:
> Cannot compile under Fedora 8.? Packages for glib, glib-devel, glibc,
> glibc-devel, gtk+, and gtk+-devel are loaded.? Suggestions?

You have to install at least these packages:

gnutls-devel
glib2-devel
gtk2-devel
libxml2-devel

--
Christian

------------------------------

-------------------------------------------------------------------------
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 26, Issue 2
*************************************************

gtk-gnutella-devel Digest, Vol 26, Issue 1

2008-11-10T23:11:55Z

>
> I have committed some changes to core/qrp.c (r15843),
>
> Change qrp_can_route to use a function pointer in the routing_table
> structure. Groups of route decision routines optimize for tables
> tables from 16k to 2M (corresponding to 14 to 21 bits), in URN and
> non-URN version are 'templated'. The fixed shift allows compilers
> to do a much better job of precomputing work.
>
> Profiling indicates that the 2^16 and 2^17 are the most common
> tables sizes (most likely due to lime wire). However, all variants
> were left. The code size is very small compared to the table
> sizes. Also, the hottest routines will be cached. It may be more
> sensible to order the URN and non-URN together (same cache page).
> However, it seems that URN searches are very rare (not supported by
> LW?).
>
> Alternate data structures could be employed with the function
> pointer method. Sparse tables could be represented by a trees.
> Alternate function pointers could decode tables in either array
> format or tree format; However, the tree structure would trade time
> for space.
>
> My system has a dynamic clock [Intel Prescott]. The rates are 400,
> 800, 1200, 2400, 3200 MHz. Previously, the CPU would spend time in
> many of the ranges. With these changes, it is staying in the 400/800
> MHz range (also 8deg C cooler). Top measurements are useless with a
> dynamic clock. 'gprof' also indicates an improvement. However,
> multiple measurements are probably best for performance improvements.
>
> If you have top numbers before/after getting r15843 as an ultra-node.
> It might be helpful to know if these changes should stay. Although,
> the changes should be architecture independent.

Isn't this a bit absurd? Maybe I'm missing something but all I can see
is that your code adds these two optimizations:

32 - variable -> const
hashcode >> variable -> hashcode >> const

It adds two assertion checks, one level of indirection and increases
the code size. Sure, the negatives might not outweigh the optimization
on average but I don't understand how these fairly minor optimizations
could make a significant difference. That is, unless the CPU design
is a complete failure. The website that shall not be named also claims
that the temperature sensor on the Prescott is reporting too high
values which means the performance difference is likely exaggerated
if measured in terms of temperature. By the way, the temperature
measurements reported in Celsius, Fahrenheit or Kelvin by diagnosis
tools are always fairly off anyway because these sensors don't work like
thermometers:

http://www.heise-online.co.uk/news/IDF-Why-many-system-info-tools-give-incorrect-CPU-temperatures--/111384

If this code is really so sensitive to optimization, I'd like to know
whether removing those assertion checks makes a significant difference.
Changing the loop to count towards zero might also gain a tiny
improvement. If non-constant shifting is so expensive, RT_SLOT_READ()
could use a small lookup-table instead.

--
Christian

------------------------------

Message: 2
Date: Wed, 17 Sep 2008 11:55:48 -0500
From: Bill Pringlemeir <bpringle@...>
Subject: Re: [gtk-gnutella-devel] QRP changes.
To: gtk-gnutella-devel@...
Message-ID: <87vdwuvhij.fsf@...>
Content-Type: text/plain; charset=us-ascii

On 17 Sep 2008, christianbiere@... wrote:

> Isn't this a bit absurd? Maybe I'm missing something but all I can see
> is that your code adds these two optimizations:
>
> 32 - variable -> const
> hashcode >> variable -> hashcode >> const

The hashcode is also used in the inline function RT_READ_SLOT. I
added the asserts to protect against error on my part in this
implementation. They can be removed if there are no reported
problems. However, I was also unsure whether the URN lookups are
supported? The splitting of the URN case is also a fairly large gain.
For a non-URN lookups, there is only one branch (if versus if/else).
Non-URN seems to be the most common form of query; this test can be
moved to the caller which can be constant over the node iteration. A
call through a function pointer is not usually that big a hit (there
was a function call to a fixed address already). Not having a has_urn
variable also seems to decrease register pressure. The code size is
very small compared to the 2-256k tables.

Try objdump -S qrp.o to see the code size difference between
qrp_can_route_default and the macro code. For cases like
'qrp_can_route_16', shifts are not always needed as 32/16/8 bit
manipulation can accomplish some of the work. The 'qrp_can_route_16'
is the most common case in any runs I have observed. Also not the
frame addressing [on x86 like -0x15(%epb)]. In the macro version,
most variables are in registers.

Regarding the temperature, I do not take it to be completely accurate.
However, all three temperature sensors have decrease by similar
amount. Eight degrees is significant. If it were two or three
degrees it would not be; I realize they are not high precision
instruments. The clock frequency reported by 'powertop' would also
have be out (and gprof, etc). I am looking into disabling the
frequency switching to get more accurate numbers via vmstat and top.

However, it is still beneficial to know if it performs better on PPC,
etc.

Sorry about the C++ comments. Emacs did that automatically.

Regards,
Bill Pringlemeir.

------------------------------

Message: 3
Date: Wed, 17 Sep 2008 19:15:26 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] QRP changes.
To: gtk-gnutella-devel@...
Message-ID: <20080917171526.GA27745@...>
Content-Type: text/plain; charset=utf-8

Bill Pringlemeir wrote:
> On 17 Sep 2008, christianbiere@... wrote:
>
> > Isn't this a bit absurd? Maybe I'm missing something but all I can see
> > is that your code adds these two optimizations:
> >
> > 32 - variable -> const
> > hashcode >> variable -> hashcode >> const
>
> The hashcode is also used in the inline function RT_READ_SLOT.

Yes, but the shifted hashcode isn't a constant, so RT_READ_SLOT()
can hardly benefit from the constant shift value.

> I added the asserts to protect against error on my part in this
> implementation. They can be removed if there are no reported
> problems. However, I was also unsure whether the URN lookups are
> supported?

For the moment being, they are still routed. gtk-gnutella in
current SVN does not insert URNs in the QRT any longer, so
URN queries can never match locally. LimeWire and derivatives
haven't inserted URNs into the QRT for years. I believe they
support single-hop URN queries though.

> The splitting of the URN case is also a fairly large gain.
> For a non-URN lookups, there is only one branch (if versus if/else).
> Non-URN seems to be the most common form of query; this test can be
> moved to the caller which can be constant over the node iteration. A
> call through a function pointer is not usually that big a hit (there
> was a function call to a fixed address already). Not having a has_urn
> variable also seems to decrease register pressure. The code size is
> very small compared to the 2-256k tables.

Sure, but I think code cache much smaller than data cache. I wasn't
trying to say that this is a problem with your optimization but
it's a negative factor no matter how minor it may be.

> Try objdump -S qrp.o to see the code size difference between
> qrp_can_route_default and the macro code. For cases like
> 'qrp_can_route_16', shifts are not always needed as 32/16/8 bit
> manipulation can accomplish some of the work. The 'qrp_can_route_16'
> is the most common case in any runs I have observed. Also not the
> frame addressing [on x86 like -0x15(%epb)]. In the macro version,
> most variables are in registers.

Are you compiling with any -march flag? I believe for most of the code
optimizations are largely irrelevant but code like this will often
benefit significantly from CPU-specific optimizations.

--
Christian

------------------------------

Message: 4
Date: Wed, 17 Sep 2008 21:40:58 -0500
From: Bill Pringlemeir <bpringle@...>
Subject: Re: [gtk-gnutella-devel] QRP changes.
To: gtk-gnutella-devel@...
Message-ID: <878wtq18hx.fsf@...>
Content-Type: text/plain; charset=us-ascii

>> On 17 Sep 2008, christianbiere@... wrote:

>>> Isn't this a bit absurd? Maybe I'm missing something but all I can see
>>> is that your code adds these two optimizations:

> Bill Pringlemeir wrote:

>>> 32 - variable -> const
>>> hashcode >> variable -> hashcode >> const

>> The hashcode is also used in the inline function RT_READ_SLOT.

On 17 Sep 2008, christianbiere@... wrote:

> Yes, but the shifted hashcode isn't a constant, so RT_READ_SLOT()
> can hardly benefit from the constant shift value.

It looks like this,

const guint shift = 32 - bits; \
guint32 idx = qhv->vec[i].hashcode >> shift; \
RT_SLOT_READ -> return 0 != (arena[idx >> 3] & (0x80U >> (i & 0x7)));

So if bits is 16, it is

shift = 32 - 16 = 16
idx = hash >> 16

*** RT_SLOT_READ arena[ hash >> 16 >> 3 ] & 0x80 >> (hash >> 16 & 7)

There are many more constant shift than there use to be. For all x86
machines this is actually a big win as the variable shift has to be in
the 'c' register (afaik). So the calculated shift has to be loaded
into cx. I agree that x86 is stupid, but it also widely used. I also
wanted to make sure that I didn't harm any other processors like the
PPC, ARM, MIPS, etc. I think that majority of processors are x86 or
PPC.

> Sure, but I think code cache much smaller than data cache. I wasn't
> trying to say that this is a problem with your optimization but
> it's a negative factor no matter how minor it may be.

True. It ends up that many of the routines are unused. Only the 16
and 17 non-URN are the frequent cases (80%+). However, I think that
these two routines are about the size of the original general case
(about 40 instruction each versus 80 for the original). The unused
code is just occupying RAM (like the tables).

> Are you compiling with any -march flag? I believe for most of the code
> optimizations are largely irrelevant but code like this will often
> benefit significantly from CPU-specific optimizations.

I do compile with flags specific to my CPU. However, I never looked
at the assembler until your post. gprof was indicating better
performance, but when I look at the number closely they don't seem to
make total sense. My processor isn't switching frequencies as much,
but this could be just due to network variance.

Did you see no difference with whatever machine(s) you have?

Thanks,
Bill Pringlemeir.

------------------------------

Message: 5
Date: Thu, 18 Sep 2008 17:59:30 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] QRP changes.
To: gtk-gnutella-devel@...
Message-ID: <20080918155930.GA27426@...>
Content-Type: text/plain; charset=utf-8

Bill Pringlemeir wrote:

> >> On 17 Sep 2008, christianbiere@... wrote:
>
> >>> Isn't this a bit absurd? Maybe I'm missing something but all I can see
> >>> is that your code adds these two optimizations:
>
> > Bill Pringlemeir wrote:
>
> >>> 32 - variable -> const
> >>> hashcode >> variable -> hashcode >> const
>
> >> The hashcode is also used in the inline function RT_READ_SLOT.
>
> On 17 Sep 2008, christianbiere@... wrote:
>
> > Yes, but the shifted hashcode isn't a constant, so RT_READ_SLOT()
> > can hardly benefit from the constant shift value.
>
> It looks like this,
>
> const guint shift = 32 - bits; \
> guint32 idx = qhv->vec[i].hashcode >> shift; \
> RT_SLOT_READ -> return 0 != (arena[idx >> 3] & (0x80U >> (i & 0x7)));

I looked at the generated code and the variants really only differed
with respect to the constants used for the shift opcodes. Otherwise,
the code and size was identical. There are no further shortcuts
applied. I think the only case where some additional optimization
was possible is "shift = 16" but you have to do that manually, GCC
at least doesn't make use of it. Maybe not because it doesn't know
but because it's not worth. Assembly wisdom, especially with respect
to x86, becomes outdated very quickly.

> So if bits is 16, it is
>
> shift = 32 - 16 = 16
> idx = hash >> 16
>
> *** RT_SLOT_READ arena[ hash >> 16 >> 3 ] & 0x80 >> (hash >> 16 & 7)
>
> There are many more constant shift than there use to be. For all x86
> machines this is actually a big win as the variable shift has to be in
> the 'c' register (afaik). So the calculated shift has to be loaded
> into cx. I agree that x86 is stupid, but it also widely used. I also
> wanted to make sure that I didn't harm any other processors like the
> PPC, ARM, MIPS, etc. I think that majority of processors are x86 or
> PPC.

I've supplied three different variants now. The one using a lookup
table to avoid shifting 0x80 seems to yield the smallest code. It's
not necessarily the fastest. Using div() looks worthwhile to me
as on x86 div yields both quotient and remainder and it's although
fast on modern x86, so it could be faster than doing two shifts
even if it increases code size slightly.

qrp_can_route_?? should be smaller by about 30% now. Compiling with
the default flags (that is -O2 and no -march) yields 104 byte for
these functions here and it was about 150 before (after removing
the assertion checks).

The most significant improvement comes actually from using qhv->count
differently (saving 31 byte). Using it as loop condition was very
sub-optimal. Of course that's also due to the small size of the
function. In a larger function where registers are spilled all the time,
it wouldn't matter.

> I do compile with flags specific to my CPU. However, I never looked
> at the assembler until your post. gprof was indicating better
> performance, but when I look at the number closely they don't seem to
> make total sense. My processor isn't switching frequencies as much,
> but this could be just due to network variance.
>
> Did you see no difference with whatever machine(s) you have?

So far I didn't benchmark any of it. While a micro-benchmark doesn't
necessarily yield realistic results, the macro benchmark depends on
far too many factors. I expect just being connected to a few leaves with
large QRTs could make a significant difference that would completely
overshadow your optimizations.

--
Christian

------------------------------

Message: 6
Date: Tue, 11 Nov 2008 18:11:44 +1100
From: Robbie <robbiesyd@...>
Subject: [gtk-gnutella-devel] Starting out with gtk-gnutella
development
To: gtk-gnutella-devel@...
Message-ID:
<addd36b60811102311h2d2499di626bd1b3a2bc4ee3@...>
Content-Type: text/plain; charset="iso-8859-1"

Whats the difference between a gnutella header and a gnutella message?
Is there any?

If there is, how is http involved? Is it just used for connecting, uploading
and downloading or is it used for
everything else as well?

Whats a safe, harmless header/message (both a header and message if theyre
different) that I can send at any time in an existing gnutella connection,
to a gnutella servent so that I can test my header/message sending
abilities? Im going to connect with gtk-gnutella and have its source code
send the header/message to the node.

I have found the gnutella_node object as well as the gnutella_socket, and I
can get a file descriptor for that
socket. I tried to send() an X-Alt header in ascii text (as defined in the
huge specification) to the file descriptor and the remote host disconnected
me (I was assuming that might be a safe header to send).

Anybody know where the function in gnutella is to send a header object or do
you just manually write to the socket's file descriptor? gtk-gnutella doesnt
have much documentation.

Regards,
Robbie
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

-------------------------------------------------------------------------
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 26, Issue 1
*************************************************

gtk-gnutella-devel Digest, Vol 25, Issue 3

2008-09-17T06:31:11Z

> Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel:
> :Then what is the purpose of checking 'lid'? It seems pmi->nl can actually
> :be a dangling pointer and this is the point of the check. The code could
> :be made standard compliant by using pmi->lid instead of pmi->nl because
> :'lid' already maps to either 'nl' or NULL. Likewise, 'nl' could be carried
> :around as an integer instead of a pointer. Admittedly, a GarbageHashTable
> :defeats this by casting it back to a pointer - if you use that directly
> :as key - which you don't have to.
>
> I perfectly know I'm handling a possibly dangling pointer value, and this
> is the purpose of the hash table.

Just a few mails ago you claimed there is no dangling pointer. I only
wrote the lengthy description because you refused to explain the purpose.

> I know I could have used an ID in the
> table, but as it is a running count it would have meant using a 64-bit
> ID and that would imply the use of 64-bit atoms, and I don't want that.

I never claimed you don't know what you're doing. Apparently you know
quite well that what you do is a hack and an unnecessary one at that.

> But let's face it: this code works fine as it is.

I don't know that.

> An implementation of a
> C compiler that would put a level of indirection to all pointer accesses
> just to prevent using a pointer that has been freed would be braindead.

It's not as braindead as exploits made possible by buffer overflows after
30 years and more of experience with C. Also you seem to think that your
idea of why this might be invalid is the only possibility. Don't you
think that someone coding for MS-DOS would consider it absurd that you
mustn't dereference NULL? Even on some Unix-like systems it might not
cause any crash or other problems. In fact, not long ago, many allowed
you to map memory at address 0x0.

> Otherwise, if one handles the actual pointer value not like a pointer but
> as any normal integer quantity, then it is perfectly safe.

Yes, once casted to an integer it follows the rules of integer arithmetic
instead of pointer arithmetic but the code doesn't do this.

> Show me a C compiler that breaks that behaviour, i.e. which breaks the logic
> of lookup_is_alive().

The standard permits such a compiler or rather such hardware. That's good
enough for me. It wouldn't be hard to modify an existing compiler to catch
exactly that i.e., abort the program if you try to load a pointer address
that doesn't correspond to allocated memory.

> :> Also, these pointers are always allocated as far as the implementation
> :> goes because they were allocated through malloc() underneath. The walloc()
> :> layer on top of that merely redistributes the allocated space among objects,
> :> but the space is not really freed. None of this memory is really freed.
> :
> :A very poor excuse. walloc() is supposed to be transparent to malloc() and
> :you can compile gtk-gnutella so that it uses malloc() all the time. In
> :fact for debugging that's highly recommended and by not adhereing to
> :the standard you make just this more difficult.
>
> Again, that would be Crappy, not C. Now if I were to dereference a dangling
> pointer, that would be a severe bug and it would warrant an immediate fix.

I don't see the problem. On MS-DOS you can dereference any pointer you like.
Looks more like cherry-picking to me.

> P.S: Actually, that particular logic is older than you would think.

Knowing that you base your knowledge of C mainly on deprecated K&R this isn't
as surprising to me as you might have expected.

> And it has been running just fine for the past 4 years in gtk-gnutella already.
> Just look at dq_alive().

Yeah, I already knew I had seen this elsewhere but two wrongs don't make a
right.

--
Christian

------------------------------

Message: 6
Date: Wed, 17 Sep 2008 08:55:26 -0500
From: Bill Pringlemeir <bpringle@...>
Subject: [gtk-gnutella-devel] QRP changes.
To: gtk-gnutella-devel@...
Message-ID: <87od2mc1wx.fsf@...>
Content-Type: text/plain; charset=us-ascii

I have committed some changes to core/qrp.c (r15843),

Change qrp_can_route to use a function pointer in the routing_table
structure. Groups of route decision routines optimize for tables
tables from 16k to 2M (corresponding to 14 to 21 bits), in URN and
non-URN version are 'templated'. The fixed shift allows compilers
to do a much better job of precomputing work.

Profiling indicates that the 2^16 and 2^17 are the most common
tables sizes (most likely due to lime wire). However, all variants
were left. The code size is very small compared to the table
sizes. Also, the hottest routines will be cached. It may be more
sensible to order the URN and non-URN together (same cache page).
However, it seems that URN searches are very rare (not supported by
LW?).

Alternate data structures could be employed with the function
pointer method. Sparse tables could be represented by a trees.
Alternate function pointers could decode tables in either array
format or tree format; However, the tree structure would trade time
for space.

My system has a dynamic clock [Intel Prescott]. The rates are 400,
800, 1200, 2400, 3200 MHz. Previously, the CPU would spend time in
many of the ranges. With these changes, it is staying in the 400/800
MHz range (also 8deg C cooler). Top measurements are useless with a
dynamic clock. 'gprof' also indicates an improvement. However,
multiple measurements are probably best for performance improvements.

If you have top numbers before/after getting r15843 as an ultra-node.
It might be helpful to know if these changes should stay. Although,
the changes should be architecture independent.

Regards,
Bill Pringlemeir.

------------------------------

Message: 7
Date: Wed, 17 Sep 2008 13:31:14 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] QRP changes.
To: gtk-gnutella-devel@...
Message-ID: <gar0r2$gpm$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Bill Pringlemeir <bpringle@...> from ml.softs.gtk-gnutella.devel:
:I have committed some changes to core/qrp.c (r15843),
:
: Change qrp_can_route to use a function pointer in the routing_table
: structure. Groups of route decision routines optimize for tables
: tables from 16k to 2M (corresponding to 14 to 21 bits), in URN and
: non-URN version are 'templated'. The fixed shift allows compilers
: to do a much better job of precomputing work.

Thanks, that looks good.

I note you used "//" comments. These should be bannished and you should
use block comments instead.

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 3
*************************************************

gtk-gnutella-devel Digest, Vol 25, Issue 2

2008-09-16T08:17:16Z

> 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
*************************************************

gtk-gnutella-devel Digest, Vol 25, Issue 1

2008-09-08T23:59:37Z

gtk-gnutella-devel Digest, Vol 24, Issue 2

2008-08-24T12:23:18Z

> In file included from ./lib/host_addr.h:42,
> from core/ban.h:40,
> from main.c:41:
> ./lib/endian.h:223:2: error: #error "This architecture may be
> unsupported. float must use IEEE 754."
> In file included from ./core/rx.h:41,
> from ./if/core/downloads.h:34,
> from ./if/core/fileinfo.h:31,
> from core/share.h:49,
> from core/fileinfo.h:40,
> from core/downloads.h:43,
> from core/dmesh.h:40,
> from main.c:47:
> ./lib/pmsg.h: In function ?pmsg_write_float_be?:
> ./lib/pmsg.h:392: warning: implicit declaration of function
> ?poke_float_be32?
> ./lib/pmsg.h:392: warning: assignment makes pointer from integer
> without a cast
> make[2]: *** [main.o] Error 1
> make[1]: *** [subdirs] Error 1
> make: *** [all] Error 2

- Matt

------------------------------

Message: 7
Date: Sun, 24 Aug 2008 13:30:55 -0500
From: "Mitch Harder (aka DontPanic)" <mmharder@...>
Subject: Re: [gtk-gnutella-devel] Patch for Search Stats
To: gtk-gnutella-devel@...
Message-ID:
<89ed0c690808241130h1f92b2cetbd90355f76555cc2@...>
Content-Type: text/plain; charset=ISO-8859-1

Thanks, those look interesting.

Give me some time to look at implementing this the same way.

On Sun, Aug 24, 2008 at 1:14 PM, Christian Biere <christianbiere@...> wrote:
>
> Look for SORTABLE in these files:
> src/ui/gtk/gtk2/fileinfo.c
> src/ui/gtk/gtk2/search.c
>
> --
> Christian

------------------------------

Message: 8
Date: Sun, 24 Aug 2008 21:24:28 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Endian compile failure on PPC7450
(back from ignomy)
To: gtk-gnutella-devel@...
Message-ID: <20080824192428.GC19643@cyclonus>
Content-Type: text/plain; charset=utf-8

Matthew Lye wrote:
> Hey,
>
> Putting the GUID debacle behind us. Ahem.
>
> I've been noticing this lately, so I ran build.sh for a 'clean' (un-
> fiddled with) version of GTKG, and got the same error. Basically, the
> __powerpc__ token isn't defined on my machine.

You can peek at such definitions like this:
echo | gcc -E -g3 -

I guess your system defined __ppc__ and it should be semantically
equivalent to __powerpc__, except for endianness maybe but that
doesn't matter here.

> I don't know when or
> how in the compile this is supposed to happen, nor how to track it
> down, but I suspect that (a) gcc-darwin uses a different token for the
> processor or (b) this breaks compiles which are optimized for a
> particular PPC chip. [This last point just occurred to me.]
>
> For myself, I just threw in
> > #define __powerppc__
> right before the IEEE 754 check, and everything worked fine.

That's not recommendable.

--
Christian

------------------------------

-------------------------------------------------------------------------
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 24, Issue 2
*************************************************

gtk-gnutella-devel Digest, Vol 24, Issue 1

2008-08-16T08:46:25Z

> On 13 Aug 2008, Raphael_Manfredi@... wrote:
>> Quoting Bill Pringlemeir <bpringle@...> from
>> ml.softs.gtk-gnutella.devel:
>>> I have a headless ultra running with the DHT code enabled,
>>>
>>> FATAL: Assertion failure in lookup.c:985: "!patricia_contains(nl->path,
>>> kn->id)"
>>> CRASH (pid=30320) by SIGABRT
>>
>> There's no such line in the latest version. Can you try with r15581?

> r15590

Sorry, I am way behind (I see many new relevant changes). I think
this was probably an intermediate not suitable for general
consumption.

------------------------------

Message: 5
Date: Thu, 14 Aug 2008 08:21:55 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] DHT assert.
To: gtk-gnutella-devel@...
Message-ID: <g80pv3$aqq$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Bill Pringlemeir <bpringle@...> from ml.softs.gtk-gnutella.devel:
:On 14 Aug 2008, bpringle@... wrote:
:Sorry, I am way behind (I see many new relevant changes). I think
:this was probably an intermediate not suitable for general
:consumption.

Well, this is brand new code that has not been completely stabilized yet.
All the trivial buglets have been found, now the hard ones remain. Little
mistakes made whilst developping which are now difficult to find and
cause problems to pop up, like the one you are encountering (which I never
did -- different conditions on your side).

I think all these problems come down to one thing: I have forgotten somewhere
to increment a ref counter on the Kademlia node object (knode_t *) and then
it's wrongly freed too early and replaced by another one, whereas the code
expected the old object to still be around.

I'm chasing another manifestation of the bug that I have encountered.

Raphael

------------------------------

Message: 6
Date: Thu, 14 Aug 2008 16:16:06 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] DHT assert.
To: gtk-gnutella-devel@...
Message-ID: <g81lo6$1gd$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Bill Pringlemeir <bpringle@...> from ml.softs.gtk-gnutella.devel:
:r15590

I found a missing refcount thanks to additional assertions. That could
explain your symptoms. Please update and let me know how it goes.

Raphael

------------------------------

Message: 7
Date: Sat, 16 Aug 2008 11:40:50 -0500
From: Bill Pringlemeir <bpringle@...>
Subject: Re: [gtk-gnutella-devel] DHT assert.
To: gtk-gnutella-devel@...
Message-ID: <87fxp4rjzh.fsf@...>
Content-Type: text/plain; charset=iso-8859-1

On 14 Aug 2008, Raphael_Manfredi@... wrote:

> I found a missing refcount thanks to additional assertions. That could
> explain your symptoms. Please update and let me know how it goes.

That certainly did seem to fix the problem. Previously runs were only
averaging 1/2 hour or less until an assertion. With revision 15637, I
was running for over 10 hours before an assertion [the trace is
completely different]. I am not even sure it is DHT related; maybe it
is a side effect?

fwiw,
Bill Pringlemeir.

08-08-16 09:54:33 (MESSAGE): DHT traffic from new firewalled node cad39d14f7b216bb28851c70e80314117211e630 at 98.213.136.92:0 (LIME v0.0)
08-08-16 09:54:33 (MESSAGE): DHT STORE valid security token from 98.213.136.92:0 (LIME v0.0) [cad39d14f7b216bb28851c70e80314117211e630] "unknown", ref=1
08-08-16 09:54:33 (MESSAGE): DHT STORE a2ef95b4f7246f335f43838ecc29500ea432b713 as ALOC v0.1 (66 bytes) created by 98.213.136.92:0 (LIME v0.0) [cad39d14f7b216bb28851c70e80314117211e630] "unknown", ref=1 (original)
08-08-16 09:54:33 (MESSAGE): DHT STORE status for a2ef95b4f7246f335f43838ecc29500ea432b713 is 8 (Creator is not acceptable)
08-08-16 09:54:34 (MESSAGE): DHT traffic from new firewalled node a2e92ea485ff09f668c0fbbe83aa04f63a66c557 at 12.205.249.123:0 (LIME v0.0)
08-08-16 09:54:34 (MESSAGE): DHT traffic from new firewalled node 70352a09dd779a287339da1d58b6ad8cde722294 at 127.0.0.1:0 (LIME v0.0)
08-08-16 09:54:34 (MESSAGE): DHT STORE valid security token from 127.0.0.1:0 (LIME v0.0) [70352a09dd779a287339da1d58b6ad8cde722294] "unknown", ref=1
08-08-16 09:54:34 (MESSAGE): DHT STORE a2efd568ac71fc342be8bbcf543eaefc372e9663 as ALOC v0.1 (65 bytes) created by 127.0.0.1:0 (LIME v0.0) [70352a09dd779a287339da1d58b6ad8cde722294] "unknown", ref=1 (original)
08-08-16 09:54:34 (MESSAGE): DHT STORE status for a2efd568ac71fc342be8bbcf543eaefc372e9663 is 8 (Creator is not acceptable)
08-08-16 09:54:34 (MESSAGE): DHT starting alive check on k-bucket a2a0000000000000000000000000000000000000 (depth 11) (good: 16, stale: 12, pending: 0)
08-08-16 09:54:34 (MESSAGE): DHT traffic from known good node 57c8d5e37a67c42b64a7501f9b1ffe753efa5709 at 61.203.68.233:50165 (LIME v0.0)
08-08-16 09:54:34 (MESSAGE): DHT traffic from known good node a2e8af1fe8412556ea23d6f7ec23d9ecc2a57347 at 24.17.236.147:9455 (LIME v0.0)
08-08-16 09:54:34 (MESSAGE): DHT STORE valid security token from 24.17.236.147:9455 (LIME v0.0) [a2e8af1fe8412556ea23d6f7ec23d9ecc2a57347] "good", ref=2
08-08-16 09:54:34 (MESSAGE): DHT STORE a2e8adb2d63bafb9d6aa6c6e36f2cc86085ea629 as PROX v0.0 (97 bytes) created by 82.36.60.119:3312 (LIME v0.0) [5abc39e898573ddff379fc0f26a8c8555d1f72d5] "unknown", ref=1 (copy)
08-08-16 09:54:34 (MESSAGE): DHT STORE status for a2e8adb2d63bafb9d6aa6c6e36f2cc86085ea629 is 12 (Replicated data is different)
FATAL: Assertion failure in gnet_stats.c:373: "i != 0"
CRASH (pid=14304) by SIGABRT

(gdb) where
#0 0x4034e967 in sigsuspend () from /lib/libc.so.6
#1 0x08153240 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 0x08156193 in assertion_failure (data=<value optimized out>)
at fast_assert.c:96
#6 0x080aac3c in gnet_stats_count_flowc (head=0x4233173c) at gnet_stats.c:373
#7 0x080bb4d7 in make_room_header (q=0x4156ca10,
header=0x42870564 "\004TC~?\212o?#a\026s\005S?", prio=0, needed=124,
offset=0xbf864e98) at mq.c:1164
#8 0x080bb838 in make_room (q=0x4156ca10, mb=0x41abeb40, needed=252,
offset=0xbf864e98) at mq.c:1025
#9 0x080bbe61 in mq_puthere (q=0x4156ca10, mb=0x41abeb40, msize=252)
at mq.c:1233
#10 0x08137179 in mq_udp_putq (q=0x4156ca10, mb=0x41e44990, to=0xbf864f5d)
at mq_udp.c:410
#11 0x0813752c in mq_udp_node_putq (q=0x4156ca10, mb=0x41e44990, n=0x407af000)
at mq_udp.c:469
#12 0x080e12c7 in send_pong (n=0x407af000, control=0,
flags=<value optimized out>, hops=0 '\0', ttl=1 '\001',
muid=0x407af124 "\004TC~?\212o?#a\026s\005S?", info=0xbf865398,
meta=0x8265740) at pcache.c:471
#13 0x080e1b24 in send_personal_info (n=0x407af000, control=0,
flags=<value optimized out>) at pcache.c:643
#14 0x080e250d in pcache_ping_received (n=0x407af000) at pcache.c:1868
#15 0x080c756e in node_parse (node=0x407af000) at nodes.c:6755
#16 0x080c8254 in node_udp_process (s=0x4073d240) at nodes.c:7120
#17 0x0811d3ce in udp_received (s=0x4073d240, truncated=0) at udp.c:266
#18 0x0810e3a1 in socket_udp_event (data=0x4073d240, unused_source=8,
cond=<value optimized out>) at sockets.c:2393
#19 0x0815f6ae in dispatch_poll (unused_source=0x82b0288,
unused_cond=G_IO_IN, udata=0x8294c00) at inputevt.c:714
#20 0x400d87cd in g_io_channel_unix_get_fd () from /usr/lib/libglib-2.0.so.0
#21 0x400a22f1 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#22 0x400a5983 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0
#23 0x400a5ea2 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#24 0x08119dca in topless_main_run () at topless.c:49
#25 0x0804e3eb in main (argc=6, argv=0xbf8659f4) at main.c:1435
(gdb) frame 15
(gdb) p *node
$1 = {magic = NODE_MAGIC, peermode = NODE_P_UDP,
start_peermode = NODE_P_LEAF, error_str = '\0' <repeats 255 times>,
socket = 0x4073d240, country = 442, proto_major = 0 '\0',
proto_minor = 6 '\006', qrp_major = 0 '\0', qrp_minor = 0 '\0',
uqrp_major = 0 '\0', uqrp_minor = 0 '\0',
vendor = 0x4078f524 "Pseudo UDP node (IPv4)", vcode = {u32 = 0},
io_opaque = 0x0,
header = "\004TC~?\212o?#a\026s\005S?\000\000\001\000\b\000\000", extvec = {
{ext_name = 0x81a2768 "SCP", ext_token = EXT_T_GGEP_SCP,
ext_type = EXT_GGEP, opaque = 0x424e4268}, {ext_name = 0x0,
ext_token = EXT_T_UNKNOWN_GGEP, ext_type = EXT_GGEP, opaque = 0x0}, {
ext_name = 0x81a274b "LOC", ext_token = EXT_T_GGEP_LOC,
ext_type = EXT_GGEP, opaque = 0x0}, {ext_name = 0x81a277b "UP",
ext_token = EXT_T_GGEP_UP, ext_type = EXT_GGEP, opaque = 0x0}, {
ext_name = 0x81a277e "VC", ext_token = EXT_T_GGEP_VC,
ext_type = EXT_GGEP, opaque = 0x0}, {ext_name = 0x81a277b "UP",
ext_token = EXT_T_GGEP_UP, ext_type = EXT_GGEP, opaque = 0x0}, {
ext_name = 0x81a277e "VC", ext_token = EXT_T_GGEP_VC,
ext_type = EXT_GGEP, opaque = 0x0}, {ext_name = 0x81a277b "UP",
ext_token = EXT_T_GGEP_UP, ext_type = EXT_GGEP, opaque = 0x0}, {
ext_name = 0x81a277e "VC", ext_token = EXT_T_GGEP_VC,
ext_type = EXT_GGEP, opaque = 0x0}, {ext_name = 0x0,
ext_token = EXT_T_UNKNOWN, ext_type = EXT_UNKNOWN,
opaque = 0x0} <repeats 23 times>}, extcount = 1, size = 8,
header_flags = 0, data = 0x8355317 "?\203SCPA", pos = 0,
status = GTA_NODE_CONNECTED, flags = 216, attrs = 0, hops_flow = 255 '?',
max_ttl = 0 '\0', degree = 0, qseen = 0x0, qrelayed = 0x0,
qrelayed_old = 0x0, qrelayed_created = 0, sent = 215417, received = 436019,
tx_dropped = 57, rx_dropped = 24912, n_bad = 0, n_dups = 0, n_hard_ttl = 0,
n_weird = 0, n_hostile = 16666, n_spam = 2331, n_evil = 0, allocated = 0,
have_header = 0, last_update = 1218898474, last_tx = 1218898474,
last_rx = 1218861290, connect_date = 1218858012,
tx_flowc_date = 1218898459, rxfc = 0x0, shutdown_date = 0,
up_date = 1218858012, leaf_flowc_start = 0, shutdown_delay = 0,
remove_msg = 0x0, addr = {net = 4, addr = {
ipv6 = "??\204y\220I?A8?*\b\000\000\000", ipv4 = 2038750372}},
port = 4585, proxy_addr = {net = 0, addr = {ipv6 = '\0' <repeats 15 times>,
ipv4 = 0}}, proxy_port = 0, outq = 0x4156ca10, searchq = 0x0, rx = 0x0,
routing_data = 0x4163a800, sent_query_table = 0x0, recv_query_table = 0x0,
qrt_update = 0x0, qrt_receive = 0x0, qrt_info = 0x0,
alive_pings = 0x840a5d8, last_alive_ping = 0, alive_period = 0, hello = {
pos = 0, len = 0, size = 0, ptr = 0x0}, tcp_rtt = 0, udp_rtt = 0,
tsync_ev = 0x0, id = 0x407f56e4, ping_throttle = 0, ping_accept = 0,
next_ping = 0, ping_guid = '\0' <repeats 15 times>,
pong_needed = "\000\000\000\000\000\000", pong_missing = 0 '\0',
gnet_addr = {net = 0, addr = {ipv6 = '\0' <repeats 15 times>, ipv4 = 0}},
gnet_port = 0, gnet_files_count = 0, gnet_kbytes_count = 0,
gnet_pong_addr = {net = 0, addr = {ipv6 = '\0' <repeats 15 times>,
ipv4 = 0}}, gnet_qhit_addr = {net = 0, addr = {
ipv6 = '\0' <repeats 15 times>, ipv4 = 0}}, guid = 0x0,
svn_release_revision = 0, n_ping_throttle = 0, n_ping_accepted = 0,
n_ping_special = 0, n_ping_sent = 0, n_pong_received = 744,
n_pong_sent = 6481, tx_given = 40094253, tx_deflated = 0,
tx_written = 40094253, rx_given = 64185665, rx_inflated = 0, rx_read = 0,
qrp_queries = 0, qrp_matches = 0, rx_queries = 0, tx_queries = 0,
rx_qhits = 100101, tx_qhits = 6758, hsep = 0x0}

(gdb) frame 10
#10 0x08137179 in mq_udp_putq (q=0x4156ca10, mb=0x41e44990, to=0xbf864f5d)
at mq_udp.c:410
(gdb) p *to
$8 = {data = {port = "\021?", ha = {net = 4 '\004',
addr = "y\204?? O\206?\004\000\000\000?N\206?"}}}

------------------------------

-------------------------------------------------------------------------
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 24, Issue 1
*************************************************

gtk-gnutella-devel Digest, Vol 23, Issue 3

2008-07-19T23:37:36Z

gtk-gnutella-devel Digest, Vol 23, Issue 2

2008-07-06T22:16:37Z

> Matthew Lye wrote:
>> I've been 'implementing' browsing of proxied hosts via command line/
>> search field[1].
>> The menu interface uses data from the original selected item to name
>> the search entry after that address.
>> It seems impossible to derive the local address from the GUID of the
>> host.
>
>> (a) Is guid_oob_get_addr_port(...)[2,3] broken,
>> (b) am I making a semantic error with *guid (assuming that it
>> is a raw 16-byte guid),
>> or
>> (c) does no-one ever encode the network bytes anymore?
>
> You might be confusing the MUID with the ServentID. The latter
> doesn't contain a port number or an IP address. The MUID contains the
> IPv4 address in queries if the querying peer or its proxying ultrapeer
> support and request out-of-band results (query hits).

I believe that I'm working with [what is consistently named] the GUID
[subsequently referred to as ServentID for disambiguation]. I've
confirmed identity via the details view in GTKG.

> I'm not sure that I understand what you're trying to achieve. What
> information do you have about the peer you want to browse?
> Do you know its ServentID?
> Do you know its IP address?
> Do you know its listening port?

I believe that all I know is (a) the ServentID [formerly GUID], a 16
hexadecimal digit string, and (b) a set of IPv4 addresses of recent
proxies of that Servent.

My main objective is to accomplish re-connection/persistence between
X11 crashes [not due to GTKG at all], which has been achieved;
sending the GUID to the proxies in a command line browse request.
i.e, "browse:f00df00df00df00d:
11.111.111.111:6036,22.222.222.222:6036,33.333.333.333:6036" [ugly
but unambiguous.]

[p.s. one can try to force tls (browse:tls:blah blah blah...), per the
other thread; not sure this is documented.]

I wish, as a secondary objective, to label the browse search results
with the IPv4:port, as happens when one selects 'browse host' from a
pop-up menu, for persistence of labeled identity.
This GUI activity uses query result data to determine the IPv4:port.

I am attempting to recover this data from the ServentID, and receive
improbable IP addresses as a result.
It may - but does not seem, to my sideline tinkerings with byte
switching, et cetera - to be an endian issue.

> --
> Christian

--
Net Neutralitarian

------------------------------

Message: 4
Date: Wed, 2 Jul 2008 09:15:11 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] GUID reliably has IPv4 at [0-4]
still?
To: gtk-gnutella-devel@...
Message-ID: <g4fguu$1h6$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel:
:I am attempting to recover this data from the ServentID, and receive
:improbable IP addresses as a result.
:It may - but does not seem, to my sideline tinkerings with byte
:switching, et cetera - to be an endian issue.

As Christian already said, the GUID is a pure random number which is not
encoding any IP address within it.

The only place whare we do encode the IP addresses is in the MUID (Message
Unique ID), located in the Gnutella header of queries for which we want
an OOB reply.

Raphael

------------------------------

Message: 5
Date: Wed, 2 Jul 2008 06:07:32 -0400
From: Matthew Lye <mlye@...>
Subject: Re: [gtk-gnutella-devel] GUID reliably has IPv4 at [0-4]
still?
To: gtk-gnutella-devel@...
Message-ID: <DE30FAC1-661C-4B4D-92AB-8059804D8B5B@...>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

On 2-Jul-08, at 5:15 AM, Raphael Manfredi wrote:
> As Christian already said, the GUID is a pure random number which is
> not
> encoding any IP address within it.

If I understand correctly now...

(a) MUID implies GUID. A GUID is just any old 16-byte string that
happens to be guaranteed to be unique. Got it.
[Probably not the most efficient way to learn about atoms.]

(b) the following is actually speaking exclusively of MUIDs and should
perhaps be clearer:

from guid.c:426-434:

> /**
> * Extract the IP and port number from the GUID of queries marked for
> OOB
> * query hit delivery.
> *
> * Bytes 0 to 3 of the guid are the 4 octet bytes of the IP address.
> * Bytes 13 and 14 are the little endian representation of the port.
> */
> void
> guid_oob_get_addr_port(const gchar *guid, host_addr_t *addr, guint16
> *port)

(c) The GUID which I *can* reliably use when calling
search_gui_new_browse_host(...) to solicit a response through a
firewall in a browse request - and hence hadn't been thinking of as
random - is generated uniquely the first time a client ever runs as a
purely random number and subsequently shouldn't change, ideally, but
it can. The span of its duration exceeds the span of its utility by
several magnitudes, giving it an unwonted salience. Analogous in some
ways to the calcification of dynamic IP addresses.

...yes?

------------------------------

Message: 6
Date: Fri, 04 Jul 2008 20:24:39 +0200
From: Raphael Manfredi <Raphael_Manfredi@...>
Subject: [gtk-gnutella-devel] DHT implementation in gtk-gnutella
To: gtk-gnutella-devel@...
Message-ID: <13203.1215195879@...>

Hello Gnutella fans,

I want to inform you that I have begun yesterday the implementation of
the DHT for gtk-gnutella, in a way that I hope will be compatible with
LimeWire's.

The Kademlia implementation itself is complex but should be rather
straightforward.

The real challenge will be in areas where LimeWire has not fully
documented what they are doing: who publishes what, when, and in which
format. However, that is "user-level" stuff, so to speak, and my aim for
now is to be able to implement the DHT core correctly and to see how it
behaves in terms of traffic and resource consumption (disk, memory, CPU).

Cheers,
Raphael

------------------------------

Message: 7
Date: Sat, 5 Jul 2008 00:43:50 +0200
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] GUID reliably has IPv4 at [0-4]
still?
To: gtk-gnutella-devel@...
Message-ID: <20080704224350.GB23947@cyclonus>
Content-Type: text/plain; charset=utf-8

Matthew Lye wrote:

> On 2-Jul-08, at 5:15 AM, Raphael Manfredi wrote:
> > As Christian already said, the GUID is a pure random number which is
> > not
> > encoding any IP address within it.
>
> If I understand correctly now...
>
> (a) MUID implies GUID. A GUID is just any old 16-byte string that
> happens to be guaranteed to be unique. Got it.
> [Probably not the most efficient way to learn about atoms.]

Yes, you can think of a GUID as a primitive data type or structure
which is used either as ServentID or MessageUID.

> (b) the following is actually speaking exclusively of MUIDs and should
> perhaps be clearer:

> from guid.c:426-434:
> > /**
> > * Extract the IP and port number from the GUID of queries marked for
> > OOB
> > * query hit delivery.
> > *
> > * Bytes 0 to 3 of the guid are the 4 octet bytes of the IP address.
> > * Bytes 13 and 14 are the little endian representation of the port.
> > */
> > void
> > guid_oob_get_addr_port(const gchar *guid, host_addr_t *addr, guint16
> > *port)

Yes, you can replace GUID with MUID here. See also how this function
is used.

> (c) The GUID which I *can* reliably use when calling
> search_gui_new_browse_host(...) to solicit a response through a
> firewall in a browse request - and hence hadn't been thinking of as
> random - is generated uniquely the first time a client ever runs as a
> purely random number and subsequently shouldn't change, ideally, but
> it can.

In newer version of gtk-gnutella a new ServentID is generated on each
startup. In other software it's probably persistent after the
initial installation.

> The span of its duration exceeds the span of its utility by
> several magnitudes, giving it an unwonted salience. Analogous in some
> ways to the calcification of dynamic IP addresses.

> ...yes?

The average uptime of a peer is supposedly less than 2 hours. I don't
think any software tries to establish persistent ultrapeer connections.
So the peer might be long offline or simply not reachable through its
previous ultrapeers if you want to browse it a couple of minutes or
hours after receiving query hits from it.

--
Christian

------------------------------

Message: 8
Date: Sun, 6 Jul 2008 14:53:38 +0200
From: Alexander Nicolaysen S?rnes <alex@...>
Subject: [gtk-gnutella-devel] Updated Norwegian translation
To: gtk-gnutella-devel@...
Message-ID: <200807061453.39215.alex@...>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

Here is an updated Norwegian Bokm?l translation, including some
fixes/improvements as well:
http://www.thehandofagony.com/alex/oversetting/gtk-gnutella/gtk-gnutella-nb-svn-20080706.tar.bz2

Once again: thanks for this great software!

Alexander N. S?rnes

------------------------------

Message: 9
Date: Mon, 7 Jul 2008 05:16:35 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Updated Norwegian translation
To: gtk-gnutella-devel@...
Message-ID: <g4s8rj$6pv$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting "Alexander Nicolaysen =?iso-8859-1?q?S=F8rnes?="
:Once again: thanks for this great software!

Thanks to you as well.
Submitted in SVN.

Raphael

------------------------------

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

End of gtk-gnutella-devel Digest, Vol 23, Issue 2
*************************************************