Gnutella Forums - 0.95 keeps crashing

Gnutella Forums (https://www.gnutellaforums.com/)

- Gtk-Gnutella (Linux/Unix/Mac OSX/Windows) (https://www.gnutellaforums.com/gtk-gnutella-linux-unix-mac-osx-windows/)

- - 0.95 keeps crashing (https://www.gnutellaforums.com/gtk-gnutella-linux-unix-mac-osx-windows/31993-0-95-keeps-crashing.html)

0.95 keeps crashing

0.95 keeps crashing pretty much says it all: I installed the Debian build at around 3 this morning, it's now 5 and it has seg faulted 5 times.

0.93 never crashed very often, but eventually the powers that be seemed to gang up on it........

There doesn't seem any consistency in the crashing. The last reads:

//snip

Outgoing b/w EMA = 256 bytes/s
Incoming b/w EMA = 4239 bytes/s
05/01/05 05:31:45 (MESSAGE): PARQ UL: Not sending QUEUE command due to another pending QUEUE command for ip: 24.132.6.5
05/01/05 05:31:45 (MESSAGE): PARQ UL: Not sending QUEUE command due to another pending QUEUE command for ip: 24.132.6.5
bsched_timer(out): delay=1009 (EMA=1010), b/w=0 (EMA=3), overused=-6199 (EMA=-6196) stolen=0 (EMA=0) unwritten=0 capped=0 (0) used 0/0
-> b/w delta=-7541904, max=6205, slot=0, first=0 (target 6144 B/s, 0 slots, real 0.00 B/s)
Outgoing b/w EMA = 252 bytes/s
Incoming b/w EMA = 4232 bytes/s
05/01/05 05:31:46 (MESSAGE): PARQ UL: Not sending QUEUE command due to another pending QUEUE command for ip: 24.132.6.5
05/01/05 05:31:46 (MESSAGE): PARQ UL: Not sending QUEUE command due to another pending QUEUE command for ip: 24.132.6.5
Query with extensions: track
> HUGE (token=3) 0 bytes
Share HIT 45 files 'track' req_speed=224 ttl=0 hops=4
Segmentation fault
john@niglo:~$

Ideas?

Re: 0.95 keeps crashing (coredump + backtrace included)

Quote:

Originally posted by fingers99
0.95 keeps crashing pretty much says it all: I installed the Debian build at around 3 this morning, it's now 5 and it has seg faulted 5 times.

0.93 never crashed very often, but eventually the powers that be seemed to gang up on it........

There doesn't seem any consistency in the crashing.

Seconded -- here's a backtrace captured from the coredump I got from taking the 0.95 src.rpm, changing the spec file's
-Doptimize="-O2"
to
-Doptimize="-g -O2"

And rpmbuild -ba 'ing it.

After running for a random length of time...

This is after I've been running 0.93.4-1 RPM for many many months, with nary a hiccup.

Developers, please contact me for more info, if needed.

Code:

(gdb) target core core

Core was generated by `gtk-gnutella'.

Program terminated with signal 11, Segmentation fault.

Loaded symbols for /usr/lib/libgtk-1.2.so.0

Loaded symbols for /usr/lib/libgdk-1.2.so.0

Loaded symbols for /usr/X11R6/lib/libXi.so.6

Loaded symbols for /usr/X11R6/lib/libXext.so.6

Loaded symbols for /usr/X11R6/lib/libX11.so.6

Loaded symbols for /lib/libm.so.6

Loaded symbols for /usr/lib/libglib-1.2.so.0

Loaded symbols for /usr/lib/libxml2.so.2

Loaded symbols for /usr/lib/libz.so.1

Loaded symbols for /lib/libresolv.so.2

Loaded symbols for /lib/libc.so.6

Loaded symbols for /usr/lib/libgmodule-1.2.so.0

Loaded symbols for /lib/libdl.so.2

Loaded symbols for /lib/ld-linux.so.2

Loaded symbols for /usr/lib/gconv/ISO8859-1.so

Loaded symbols for /lib/libnss_files.so.2

Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2

Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2

Loaded symbols for /usr/X11R6/lib/libXcursor.so.1

Loaded symbols for /usr/X11R6/lib/libXrender.so.1

#0  0x4046b5cf in malloc_consolidate () from /lib/libc.so.6

(gdb) bt

#0  0x4046b5cf in malloc_consolidate () from /lib/libc.so.6

#1  0x4046ac27 in _int_malloc () from /lib/libc.so.6

#2  0x40469e21 in malloc () from /lib/libc.so.6

#3  0x4046a06c in realloc () from /lib/libc.so.6

#4  0x402d9d64 in g_realloc () from /usr/lib/libglib-1.2.so.0

#5  0x402e46bb in g_string_chunk_insert_const () from /usr/lib/libglib-1.2.so.0

#6  0x402e4770 in g_string_sized_new () from /usr/lib/libglib-1.2.so.0

#7  0x0814d2b6 in strcpy ()

#8  0x0807a2f1 in strcpy ()

#9  0x080739fc in strcpy ()

#10 0x080c29e6 in strcpy ()

#11 0x0814e0fc in strcpy ()

#12 0x402d70a6 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0

#13 0x402d89ae in g_get_current_time () from /usr/lib/libglib-1.2.so.0

#14 0x402d8e89 in g_get_current_time () from /usr/lib/libglib-1.2.so.0

#15 0x402d9124 in g_main_run () from /usr/lib/libglib-1.2.so.0

#16 0x400cf27f in gtk_main () from /usr/lib/libgtk-1.2.so.0

#17 0x080d5fe7 in strcpy ()

#18 0x0805220b in strcpy ()

#19 0x4040c917 in __libc_start_main () from /lib/libc.so.6

(gdb)

Before I do the bad thing and install Limewire :( (which will mean trying to get the 95% and 90% ile files I've got through older versions of gtk-gnutella into a format Limewire will accept as its own) can anyone come up with a script to keep gtk-gnutella up?

I'm thinking of a cron job every 5 seconds to check if gtk-gnutella is up and if not to launch it again.

Anyone wanting debugging "dumps" just ask -- I've more than enough! :rolleyes:

Hi,

The core dumps don't really look that useable. Sorry, try to compile with -g3 only (so no -O optimisation). Then when it crashes do a bt full.
If you don't get a core dump,
> ulimit -c unlimited
should do the trick. After it dumps do a:
gdb gtk-gnutella core
and enter 'bt full'

Without a good backtrace the problem will be very hard to spot.

Wierder and wierder. I restarted it at about 4pm, left it unattended and on returning from work at 3am it's still up and downloading. Very odd.

Possible explanation is that it was something on one of the hosts which was causing my client to crash.

>> Later ........Now 22 hours uptime -- what's noticeable is that I seem to have more alive connections than with the older version. Oh joy! One of the things I've been downloading for the last 3 weeks is just about finished. :D

For the past few days, I kept running the version that got installed by the rpm -- and kept wondering why I wasn't getting more useful results =) (The executable is stripped before RPM packaging.)

Here's a dump from running the src/gtk-gnutella under gdb (I hope that aspect of running it doesn't mess up the bug behavior) -- I can run it and get a regular core to target if anyone wants.

Cheers,
buckaro0

Code:

(gdb) bt

#0  0x4046b73f in _int_realloc () from /lib/libc.so.6

#1  0x4046a10d in realloc () from /lib/libc.so.6

#2  0x402d9d64 in g_realloc () from /usr/lib/libglib-1.2.so.0

#3  0x080c5dea in flush_match () at qhit.c:318

#4  0x080c66bc in add_file (sf=0x866b0f0) at qhit.c:541

#5  0x080c6775 in qhit_send_results (n=0x89d5b7c, files=0x89fbf58, count=80, use_ggep_h=0) at qhit.c:597

#6  0x080db767 in search_request (n=0x89d5b7c, qhv=0x0) at share.c:2147

#7  0x080b20ed in node_parse (node=0x89d5b7c) at nodes.c:5487

#8  0x080b34e0 in node_read (n=0x89d5b7c, mb=0x8601db0) at nodes.c:6145

#9  0x080b35db in node_data_ind (rx=0x8b1ed70, mb=0x8601db0) at nodes.c:6176

#10 0x080d044e in rx_inflate_recv (rx=0x8b1ed70, mb=0x8601e3c) at rx_inflate.c:208

#11 0x080cff66 in rx_recv (rx=0x8b1ed70, mb=0x8601e3c) at rx.c:179

#12 0x080cfd88 in rx_data_ind (rx=0x830b978, mb=0x8601e3c) at rx.c:117

#13 0x080d0656 in is_readable (data=0x830b978, unused_source=23, cond=INPUT_EVENT_READ) at rx_link.c:105

#14 0x0819dcd5 in inputevt_dispatch (source=0x826ebb0, condition=G_IO_IN, data=0x875e26c) at inputevt.c:92

#15 0x402d70a6 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0

#16 0x402d89ae in g_get_current_time () from /usr/lib/libglib-1.2.so.0

#17 0x402d8e89 in g_get_current_time () from /usr/lib/libglib-1.2.so.0

#18 0x402d9124 in g_main_run () from /usr/lib/libglib-1.2.so.0

#19 0x400cf27f in gtk_main () from /usr/lib/libgtk-1.2.so.0

#20 0x080f9411 in main_gui_run () at main.c:677

#21 0x080523fd in main (argc=1, argv=0xbffff874, env=0xbffff87c) at main.c:646

#22 0x4040c917 in __libc_start_main () from /lib/libc.so.6

This is the same bug as this one:
https://sourceforge.net/tracker/inde...67&atid=104467

It's fixed in CVS.