won't stay running-shuts down suddenly
 

Since upgrading to gtk-gnutella .92C, the program shuts down for no appearant reason. This happens at different times of the day or night. Sometimes it stays up for several days, sometimes, only several hours.

Just now (6:23pm), I was reviewing a search result, when it decided to end itself. It just shut down. I don't see anything in any log whatsoever.

I usually notice this in the morning, when gtk-gnutella isn't running. Any other program that I leave up, such as a browser, stay running.

I'm running basically Red Hat, but have upgraded the kernal to .20 from .18


Does anyone have any ideas why this might be happening? I can't even begin to figure out what happens when it shuts down.

If you don't know why this might be happening, does anyone know how I might be able to run debugging within gtk-gnutella in the hopes of finding out why?

Thanks

Try the irc room...
 

Yea, not many of the developers hang around here just a whole lot. They're generally on irc though. Here's the post about that with the server. :)


" 2) join the irc channel #gtk-gnutella on the server irc.freenode.net. A irc client for unix systems would be for example irssi, kvirc or xchat, on windows best choice is mIRC.
Ask there. You'll maybe have to wait when noone is alive, though, so be patient."


Hope you can get some help.

Later,

Isamoor

Latest *stable* version is .92, so perhaps try to update. This *might* help.

I'm seeing almost exactly the same thing on Solaris 8 with the 0.92.1 stable version. However, I have a clue, and am working with the dev team to track the problem down.

If you have the GNU debugger installed, do a debug run of the program, and send the traceback when it breaks. That will confirm or not if you have the same problem as I do. In my case, it breaks at:

t@0 (l@1) terminated by signal SEGV (no mapping at the fault address)
0xdf06d3b1: strlen+0x000d: repnz scasb %al,(%edi)
Current function is g_io_unix_dispatch
161 user_data);

If your debugger shows anything close to this, you have the same problem, and we are working to fix it. If not, then you still need to contact the dev team, and send them the backtrace, along with enough info to help them track down what's going on.

It's possible that someone found a new way to break the client using an attack that sends a corrupted request of some kind, and it's not handled well. Or it could be something entirely different.

The debugger is simple to use, although the docs are daunting.
All you want to do is run the program from inside the debugger. You don't need to set breakpoints or anything, at least not yet.

Then you need to be able to display the backtrace, which is also a single, simple command. Catch the output, and paste it into your browser to paste it here, or your email client, to send it to the dev team.

The command to start the debugger is usually:

gdb fully_qualified_path_to_gtk-gnutella

So it might be:
gdb /usr/local/bin/gtk-gnutella

Once you are at a debug prompt, just type 'run'.
The program should start just like normally, but it might run a little slower.

When the program freezes, you will see a new prompt in the startup window. Type in 'backtrace', without the quotes.

Then copy and paste the text that is displayed into a file that you can use to keep the info around.

Once you have done that, type 'q' to quit, and you will be back at a prompt.

That's all you need to do - simple, isn't it?

Best of luck,
--Rockkeys