Valgrind found this leak in Pan using GNet 2.0.3 on Linux:

==16477== 816 bytes in 6 blocks are definitely lost in loss record 6736 of 7004
==16477==    at 0x401617F2: calloc (vg_clientfuncs.c:245)
==16477==    by 0x405EA5D0: g_malloc0 (in /usr/lib/libglib-2.0.so.0.200.1)
==16477==    by 0x4072F27E: gnet_gethostbyname (inetaddr.c:209)
==16477==    by 0x4072F6AF: gnet_inetaddr_new_list (inetaddr.c:635)
==16477==    by 0x407331C8: gnet_tcp_socket_connect (tcp.c:44)
==16477==    by 0x80A0D25: pan_socket_constructor (sockets.c:156)
==16477==    by 0x80A0ADD: pan_socket_new (sockets.c:117)
==16477==    by 0x80A19F9: connect_thread_func (socket-pool.c:126)
==16477==    by 0x405FC9F0: (within /usr/lib/libglib-2.0.so.0.200.1)
==16477==    by 0x4074D3C2: thread_wrapper (vg_libpthread.c:671)
==16477==    by 0x401651F8: do__quit (vg_scheduler.c:2154)

It appears that the GInetAddr structs g'newed in gnet_gethostbyname
should be destroyed by gnet_inetaddr_delete() when called from
gnet_tcp_socket_connect(), except there's a bug in the refcount code:

--- inetaddr.c.bak      2003-07-23 00:32:57.000000000 -0500
+++ inetaddr.c  2003-07-23 00:33:05.000000000 -0500
@@ -1590,11 +1590,11 @@
 void
 gnet_inetaddr_unref (GInetAddr* inetaddr)
 {
   g_return_if_fail(inetaddr != NULL);
  
-  inetaddr->ref_count++;
+  inetaddr->ref_count--;
  
   if (inetaddr->ref_count == 0)
     {
       if (inetaddr->name != NULL)
        g_free (inetaddr->name);