[293] in bug-owl
segfailt in aim_bstream_send
daemon@ATHENA.MIT.EDU (Erik Nygren)
Sun Nov 23 18:19:56 2003
To: bug-owl@mit.edu
cc: jtu@mit.edu
Date: Sun, 23 Nov 2003 18:18:21 -0500
From: Erik Nygren <nygren@MIT.EDU>
Message-Id: <E1AO3Uj-0001Rl-00@galaxia.bay13.org>
(gdb) where
#0 0x08198185 in aim_bstream_send (bs=0xbfffd7a0, conn=0x0, count=110) at txqueue.c:247
#1 0x08198380 in sendframe_flap (sess=0x81e4698, fr=0x8298050) at txqueue.c:290
#2 0x08198534 in aim_tx_flushqueue (sess=0x81e4698) at txqueue.c:371
#3 0x0818aae6 in aim_conn_completeconnect (sess=0x81e4698, conn=0x879e7e0) at conn.c:1017
#4 0x0808c61b in owl_aim_process_events () at aim.c:322
#5 0x08070909 in main (argc=136201196, argv=0xffffffff, env=0xbfffeabc) at owl.c:385
#6 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
Strangely, conn is not 0x0 in the caller:
(gdb) print fr->conn
$23 = (aim_conn_t *) 0x81e4914
(gdb) print *fr->conn
$24 = {fd = 0, type = 0, subtype = 0, seqnum = 6, status = 0, priv = 0x0, internal = 0x0, lastactivity = 0, forcedlatency = 0, handlerlist = 0x0, sessv = 0x0,
inside = 0x0, next = 0x0}
But that doesn't look like a valid connection at all...
Also, aim_bstream_send does check whether conn is null (and the
dereference of the null conn caused the segfault). This means that
something called between the check and the conn dereference somehow
corrupted the heap and/or stack, or had a side-effect?
Erik
