[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-gnutls] Re: hang in gnutls_bye in gaim
From: |
Simon Josefsson |
Subject: |
[Help-gnutls] Re: hang in gnutls_bye in gaim |
Date: |
Fri, 17 Mar 2006 09:52:00 +0100 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) |
Cameron Ring <address@hidden> writes:
> i'm looking into a problem with gaim 1.5 + gnutls 1.0.25 where
> disconnecting from a jabber server with TLS supprt (wildfire, in this
> case) causes gaim to hang. here's the backtrace of the hung process:
You may want to try a more recent version.
> #0 0x001017a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1 0x001e2451 in recv () from /lib/tls/libc.so.6
> #2 0x00861cdb in _gnutls_read (session=0x9ef4108, iptr=0x9ef65f8,
> sizeOfPtr=5, flags=0) at gnutls_buffers.c:217
> #3 0x008622d9 in _gnutls_io_read_buffered (session=0x9ef4108,
> iptr=0xbfe3d0d8, sizeOfPtr=5, recv_type=4294967295) at gnutls_buffers.c:408
> #4 0x0085f887 in _gnutls_recv_int (session=0x9ef4108, type=GNUTLS_ALERT,
> htype=4294967295, data=0x0, sizeofdata=0) at gnutls_record.c:680
> #5 0x00860783 in gnutls_bye (session=0x9ef4108, how=GNUTLS_SHUT_RDWR) at
> gnutls_record.c:197
> #6 0x080d8833 in ssl_gnutls_close (gsc=0x9ed84d0) at ssl-gnutls.c:135
> #7 0x080b2fa6 in gaim_ssl_close (gsc=0x9ed84d0) at sslconn.c:183
> #8 0x0811baa8 in jabber_close (gc=0x9ed7c28) at jabber.c:764
> #9 0x0809a35f in gaim_connection_disconnect (gc=0x9ed7c28) at
> connection.c:254
> #10 0x0809ac06 in gaim_connections_disconnect_all () at connection.c:616
> #11 0x080d8479 in main (argc=5, argv=0xbfe3d434) at main.c:605
>
> i'm not sure whether the problem is on the client side or the server
> (e.g. is the server not replying to our request to close the
> connection?), but i'm hoping for some pointers in the right
> direction.
Etherreal or similar might help. Or if you control the server, debug
it.
> if, indeed, the server isn't sending a reply, is there a
> way to set a timeout so the client won't wait forever for a reply that
> isnt' coming?
>
> from the application side, i guess i could grab the transport ptr and
> set a timeout on the socket before calling gnutls_bye. does that sound
> reasonable?
I think so. You could also replace the default pull/push functions
with some socket functions that use a timeout.
Regards,
Simon