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