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

View: New views

1 Messages — Rating Filter: Alert me

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

by gtk-gnutella-devel-request :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Send gtk-gnutella-devel mailing list submissions to
gtk-gnutella-devel@...

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
or, via email, send a message with subject or body 'help' to
gtk-gnutella-devel-request@...

You can reach the person managing the list at
gtk-gnutella-devel-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gtk-gnutella-devel digest..."

Today's Topics:

1. Re: Crash after Bitzi Lookup attempt (Larry Nieves)
2. Re: Crash after Bitzi Lookup attempt (Raphael Manfredi)
3. Re: Crash after Bitzi Lookup attempt (Larry Nieves)
4. Re: Crash after Bitzi Lookup attempt (Raphael Manfredi)
5. Re: Crash after Bitzi Lookup attempt (Raphael Manfredi)
6. Odd assertion failure in iso3166.c (Matthew Lye)

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

Message: 1
Date: Sun, 1 Nov 2009 09:22:29 +0100
From: Larry Nieves <lanieves@...>
Subject: Re: [gtk-gnutella-devel] Crash after Bitzi Lookup attempt
To: gtk-gnutella-devel@...
Message-ID: <20091101082229.GC19991@galar2>
Content-Type: text/plain; charset="utf-8"

On Sat, Oct 31, 2009 at 08:36:54PM +0000, Raphael Manfredi wrote:
> To validate this, can you confirm you're not compiling with -O0? Try to
> recompile with -O0 and check again. If that crashes then, it will rule out
> my hypothesis.

Yes, I can confirm the version that crashed was compiled with -O2. Next
I tried as you suggested to compile with -O0 and the crash didn't
happen. Bitzi lookups are working as expected.

> Which version of the compiler are you using, and which OS is that?

$ cc --version
cc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
$ uname -rmo
2.6.28-16-generic i686 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty

I'l be happy to give more info if needed.

Cheers,

--
Larry Alex?nder Nieves Colmen?rez <lanieves@...>
El Liberal Venezolano http://liberal-venezolano.net/
GPG Public Key: 0x3F25527E
Key Fingerprint = 3C08 E8AC DE25 CEC6 731D B9B4 BD9E 03B0 3F25 527E
gpg --recv-keys 0x3F25527E --keyserver hkp://wwwkeys.eu.pgp.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature

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

Message: 2
Date: Sun, 1 Nov 2009 08:36:34 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Crash after Bitzi Lookup attempt
To: gtk-gnutella-devel@...
Message-ID: <hcjhai$mk$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Larry Nieves <lanieves@...> from ml.softs.gtk-gnutella.devel:
:Yes, I can confirm the version that crashed was compiled with -O2. Next
:I tried as you suggested to compile with -O0 and the crash didn't
:happen. Bitzi lookups are working as expected.

So we do have a gcc optimizer bug. That's both comforting and frightnening.

Could you check whether r17150 (the current latest SVN), compiled with -O2
again, crashes during Bitzi lookups? I've changed the function where the
crash was happening to not modify the arguments (which may be confusing the
optimizer).

Unfortunately it's going to be hard to report to the GCC folks since we
don't have a small test-case to show them. We have a huge beast crashing...

Raphael

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

Message: 3
Date: Sun, 1 Nov 2009 10:10:42 +0100
From: Larry Nieves <lanieves@...>
Subject: Re: [gtk-gnutella-devel] Crash after Bitzi Lookup attempt
To: gtk-gnutella-devel@...
Message-ID: <20091101091042.GA4038@galar2>
Content-Type: text/plain; charset="utf-8"

On Sun, Nov 01, 2009 at 08:36:34AM +0000, Raphael Manfredi wrote:
> Could you check whether r17150 (the current latest SVN), compiled with -O2
> again, crashes during Bitzi lookups? I've changed the function where the
> crash was happening to not modify the arguments (which may be confusing the
> optimizer).

It crashes again.

Revision: 17150
Last Changed Rev: 17150
Last Changed Date: 2009-10-31 22:24:22 +0100 (Sat, 31 Oct 2009)

Compiled with default settings, i.e. "-O2".

>From gdb:

Core was generated by `gtk-gnutella'.
Program terminated with signal 6, Aborted.
[New process 9592]
#0 0xb7f4b430 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7f4b430 in __kernel_vsyscall ()
#1 0xb74216d0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0x0823d114 in crash_handler (signo=11) at crash.c:177
#3 <signal handler called>
#4 parse_ipv6_addr (s=0x838cca0 "bitzi.com", dst=0xbf88fff8 "", endptr=0x0) at parse.c:219
#5 0x0824caf3 in string_to_host_addr (s=0x838cca0 "bitzi.com", endptr=0x0, addr_ptr=0xbf8900f4) at host_addr.c:566
#6 0x080d2a6a in http_async_create (url=0xbe4f1584 "http://bitzi.com/rdf/urn:sha1:CRV643PAX5VDZOITYJS46MRFR2BRGAFD?ref=gtk-gnutella", addr=
{net = 0, addr = {ipv6 = '\0' <repeats 15 times>, ipv4 = 0}}, port=0, type=HTTP_GET, header_ind=0, data_ind=0x8078710 <bitzi_host_data_ind>,
error_ind=0x80787f0 <bitzi_host_error_ind>, parent=0x0) at http.c:1977
#7 0x080d2ec7 in http_async_get (url=0xbe4f1584 "http://bitzi.com/rdf/urn:sha1:CRV643PAX5VDZOITYJS46MRFR2BRGAFD?ref=gtk-gnutella", header_ind=0,
data_ind=0x8078710 <bitzi_host_data_ind>, error_ind=0x80787f0 <bitzi_host_error_ind>) at http.c:2076
#8 0x080772aa in bitzi_heartbeat (unused_data=0x0) at bitzi.c:704
#9 0xb77d12b6 in ?? () from /usr/lib/libglib-2.0.so.0
#10 0xb77d0b88 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#11 0xb77d40eb in ?? () from /usr/lib/libglib-2.0.so.0
#12 0xb77d45ba in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#13 0xb7cb17d9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#14 0x0819aa0c in main_gui_run (geometry_spec=0x0) at main.c:697
#15 0x08056f67 in main (argc=1, argv=0xbf890454) at main.c:1659

--
Larry Alex?nder Nieves Colmen?rez <lanieves@...>
El Liberal Venezolano http://liberal-venezolano.net/
GPG Public Key: 0x3F25527E
Key Fingerprint = 3C08 E8AC DE25 CEC6 731D B9B4 BD9E 03B0 3F25 527E
gpg --recv-keys 0x3F25527E --keyserver hkp://wwwkeys.eu.pgp.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature

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

Message: 4
Date: Sun, 1 Nov 2009 09:28:08 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Crash after Bitzi Lookup attempt
To: gtk-gnutella-devel@...
Message-ID: <hcjkb8$7co$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Larry Nieves <lanieves@...> from ml.softs.gtk-gnutella.devel:
:On Sun, Nov 01, 2009 at 08:36:34AM +0000, Raphael Manfredi wrote:
:> Could you check whether r17150 (the current latest SVN), compiled with -O2
:> again, crashes during Bitzi lookups? I've changed the function where the
:> crash was happening to not modify the arguments (which may be confusing the
:> optimizer).
:
:It crashes again.

Good, so we have a clean optimizer bug, but it's not easy to isolate it.

Can anybody on this list volunteer to report the bug to the gcc team
and do the necessary follow-ups? We want this bug nailed down...

BTW, there is another gcc bug to report: see the comment marked "RAM"
near the top of the src/lib/fast_assert.h file. It occurred with:

gcc (GCC) 4.2.1 20070719 [FreeBSD]

Anyone (else) want to pursue that one further as well?

Please let me know, thanks.
Raphael

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

Message: 5
Date: Sun, 1 Nov 2009 12:13:10 +0000 (UTC)
From: Raphael_Manfredi@... (Raphael Manfredi)
Subject: Re: [gtk-gnutella-devel] Crash after Bitzi Lookup attempt
To: gtk-gnutella-devel@...
Message-ID: <hcju0m$t5k$1@...>
Content-Type: text/plain; charset="iso-8859-1"

Quoting Larry Nieves <lanieves@...> from ml.softs.gtk-gnutella.devel:
:It crashes again.
:Revision: 17150

OK, try with r17153.

The problem was that we were lying to the compiler in lib/parse.h, and
that is an unforgivable sin! So the compiler was optimizing some tests
away because we told it that the parameters could not be NULL, whereas we
were passing NULL...

Thanks to Jasen Betts for finding this one.

Raphael

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

Message: 6
Date: Tue, 3 Nov 2009 11:42:28 -0500
From: Matthew Lye <mlye@...>
Subject: [gtk-gnutella-devel] Odd assertion failure in iso3166.c
To: gtk-gnutella-devel@...
Message-ID: <DDA6A6DF-99FB-495A-AD47-89D3345FA494@...>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Hey all,

I have encountered a crash that I find rather perplexing, seemingly in
iso3166.c:

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