Re: [gnet-devel] Problem with gnet_conn_disconnect()

[Tim Müller <t i m zen co uk>]

On Thu, 2008-03-20 at 20:10 +0000, Rui Coelho wrote:

Hi Rui,

> I'm using libgnet for the first time and I've run into an annoying problem. 
> Here's the scenario:
> 
> As the client thread connected is blocked in a gnet_io_channel_read() 
> waiting for incoming data, I SIGINT the server triggering a G_IO_ERROR_* to 
> the client. This behaviour seems correct to me, but when I try to close the 
> connection with this code:
> 
> if (gnet_conn_is_connected (connection))
>     {
>       g_debug ("Connection is still open");
>       gnet_conn_disconnect (connection);
>     }
> 
> When gnet_conn_disconnect () is called the program crashes:
> 
> ** (process:30154): DEBUG: Connection is still open
> *** glibc detected *** /home/rui/Projects/grabthat/src/.libs/lt-grabthat: 
> malloc(): memory corruption: 0xb7ebc177 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0xb7dde384]
> /lib/libc.so.6(__libc_malloc+0x8d)[0xb7ddfced]
> /lib/libc.so.6(vasprintf+0x23)[0xb7dd4813]
> /usr/lib/libglib-2.0.so.0(g_vasprintf+0x37)[0xb7f36557]
> /usr/lib/libglib-2.0.so.0(g_strdup_vprintf+0x26)[0xb7f27546]
> /usr/lib/libglib-2.0.so.0(g_logv+0x1b7)[0xb7f0fd67]
> /usr/lib/libglib-2.0.so.0(g_log+0x29)[0xb7f0ffd9]
> /home/rui/Projects/grabthat/src/nntp/.libs/libnntp.so.0(_nntp_end+0xaa)[0xb7ed680a]
> /home/rui/Projects/grabthat/src/nntp/.libs/libnntp.so.0(nntp_list+0x3b)[0xb7ed6aeb]
> /usr/lib/libgnet-2.0.so.0[0xb7f8f419]
> /usr/lib/libgnet-2.0.so.0(gnet_tcp_socket_new_async_cb+0xc0)[0xb7f86160]
> /usr/lib/libglib-2.0.so.0[0xb7f3692d]
> /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x176)[0xb7f072b6]
...
> Am I doing something wrong? Shouldn't I call gnet_conn_is_connected () and 
> then gnet_conn_disconnect () ?

Hard to say what's going on here. Maybe you could make your code or a
small test program available somewhere or attach it?

The stack trace indicates it's crashing in a g_log statement, so
g_debug/g_warning etc - are you sure your printf format strings are all
in order? Does your code compile without warnings with -Wall? Maybe you
could run it in gdb and/or valgrind and attach a full stack trace from
gdb?

Also, which GNet version are you using? If not 2.0.8, please give 2.0.8
a shot, which has a number of bug fixes.

Another thing: GConn is meant primarily for asynchronous I/O, driven by
a main loop, ie. you usually wouldn't use a separate client thread with
it that blocks, but rather let the main loop do the blocking on the
socket and call the callback when there's data. If you want blocking
I/O, GTcpSocket is probably better suited. If you do use GConn, you
should know what's happening under the hood, since the GNet objects
generally aren't thread-safe, so if you do something that makes GConn
add watches to the GLib main loop (iterated in the main thrad) and then
also use the very same GConn in another client thread, chances are that
bad things happen. Just saying :)

Hope this helps. If it doesn't, it's best to show us some code.

Cheers
 -Tim