gaim hangs due to gnutls, switch to nss

[Julien Pourtet]

I'm using Gaim 1.1.4 (default on Hoary, AFAIK) and each time I try to exit
freezes. However, there are two different "versions" of this bug. The first one:
I press Ctrl-Q (with the focus on the main window, of course) and Gaim freezes,
but if I click on the upper right cross a window will appear and force gaim to
quit. And the second one: I choose "quit" on the menu and the software freezes
altogether, with no magical window to make it exit. Then I can't do anything but
a savage kill -9 on the process itself.

Any idea?

[Luke Schierer (lschiere)]

1)what sort of accounts do you use?
2)if you run a ps command in a terminal, how many gaim processes do you see?

[Julien Pourtet (j-pourtet-deactivatedaccount-deactivatedaccount)]

(In reply to comment #1)
> 1)what sort of accounts do you use?
> 2)if you run a ps command in a terminal, how many gaim processes do you see?

1) I use a Jabber account exclusively (no transports and other exotic things.)
2) if I run a 'ps ax | grep gaim' in a terminal, there's only one gaim process.

Hope it helps :s

[Luke Schierer (lschiere)]

in help->about, all the way at the bottom, it lists some infromation from the
configure script's output. what does it say next to GNUTLS:
and next to
NSS:
under
SSL: Gaim was compiled with SSL support

[Julien Pourtet (j-pourtet-deactivatedaccount-deactivatedaccount)]

(In reply to comment #3)
> in help->about, all the way at the bottom, it lists some infromation from the
> configure script's output. what does it say next to GNUTLS:
> and next to
> NSS:
> under
> SSL: Gaim was compiled with SSL support

Print debugging messages: No
Binary relocation: Disabled
Plugins: Enabled
SSL: Gaim was compiled with SSL support
GNUTLS: Enabled
NSS: Disabled
Tcl: Yes
Tk: Yes
External libzephyr: Yes
Zephyr uses Kerberos: No
AO: Yes
NAS Audio: No
GtkSpell: Enabled
XScreenSaver support: Yes
X SM support: Yes

[Luke Schierer (lschiere)]

okay, that's about what I expected. Sebastien, I have a number of reports from
the last month or so about gnutls hanging in different situations. This is the
only report I have about quit, but I have seen reports of hangs on sign off,
connect, and reconnect, so it is not really beyond belief that gnutls would be
the case. You may want to consider switching to NSS from gnutls, I will be
saying much the same to Robot101 (debian gaim packager).

Julien: as a work around, go into tools->accounts and click to modify your
jabber account. click to show more options. uncheck (if checked) "use tls if
available" and check if not checked "Allow plaintext auth..."

this will not work with some servers, so if you can't connect, then switch it
back. If you can connect, I would be interested to know if this avoids the
hang on quit.

[Julien Pourtet (j-pourtet-deactivatedaccount-deactivatedaccount)]

(In reply to comment #5)
> Julien: as a work around, go into tools->accounts and click to modify your
> jabber account. click to show more options. uncheck (if checked) "use tls if
> available" and check if not checked "Allow plaintext auth..."
>
> this will not work with some servers, so if you can't connect, then switch it
> back. If you can connect, I would be interested to know if this avoids the
> hang on quit.

The workaround works perfectly. Gaim now exits without trouble. Thank you very
much ;)

[Sebastien Bacher (seb128)]

thanks Luke for tracking that, not easy to point gnutls from the bug description

[Daniel Holbach (dholbach)]

Are there any conclusions to be drawn from this bug report or any changes that
should be made?

[Sebastien Bacher (seb128)]

yep Daniel, we should build gaim with nss instead of gnutls. But a such change
require some feedback so that's probably for after 5.10 now

[Kevin Bullock (kbullock)]

It's possible this bug is triggered by an interaction between the Wildfire server and Gaim, cf.:

http://www.jivesoftware.org/community/message.jspa?messageID=114841

I have two jabber accounts using TLS, one connecting to a Wildfire server and the other to something else (unknown). Only the Wildfire account triggers the bug.

[Eric Lee (ericlee)]

I am experiencing the bug as described by Kevin with Wildfire. I have found that waiting about 10-20 minutes will bring back Gaim after such a freeze (I'm guessing the operating system detected that the socket was idle and dropped it, or something along those lines). At the bottom there is a patch for Gaim that sets the socket timeout for closing the connection to 3 seconds. I am using Gaim 1.5.0 (latest update for Dapper) with Wildfire 3.0.0.

Here's a Debian bug filed about the same issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375317

Here's the research I have done on this issue:
The SSL connection close in Wildfire (source for version 3.0.0) happens at org.jivesoftware.wildfire.net.TLSWrapper.java:188. It performs SSLEngine.closeOutBound()

I also found this:
"To close the connection the user must first inform the SSLEngine that there is no more application data to be sent and, therefore, the session should be terminated. This is done by calling SSLEngine.closeOutbound(). After this, a call to wrap() will generate a close message that must be sent to the other peer. A well-behaved program should wait for the answer to this message, but the SSL/TLS specification says that it is acceptable to close the socket after sending the initial close message. And, typically, this is the easiest solution. After being closed, an SSLEngine cannot be reused."

The above is from:
http://www.onjava.com/pub/a/onjava/2004/11/03/ssl-nio.html

To me it sounds like Gaim is demanding that the close message be received. I don't know any details about the specification, but if it is optional then Gaim should not freeze the entire application while waiting for the message.

[trollord (trollenlord)]

It's pidgin nowadays. :-) And switched to using nss (released on +1), getting rid of the specific problem for good. Also the Pidgin project's documentation recommends nss over gnutls for everyone.