search

exported / execap

Automatically exported from code.google.com/p/execap
GNU General Public License v3.0
0 stars 0 forks source link

Elusive segfault #19

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
After running for a few weeks execap segfaulted.  This is the first and only 
segfault. At this point I have no information or ideas.  Obviously there is a 
bug somewhere.

I have recompiled with debugging turned on and enabled core dumps.

[2540413.721432] execap[28543]: segfault at 37 ip 00007f28d7433103 sp 
00007fff94897798 error 6 in libc-2.10.1.so[7f28d73b4000+14f000]

Original issue reported on code.google.com by bmenr...@ucsd.edu on 14 Jan 2011 at 3:44

GoogleCodeExporter commented 9 years ago

Original comment by bmenr...@ucsd.edu on 14 Jan 2011 at 3:45

GoogleCodeExporter commented 9 years ago 
segfault happened again.  Here is the backtrace:

Program terminated with signal 11, Segmentation fault.
#0  0x00007f1a91b10103 in memcpy () from /lib/libc.so.6
(gdb) bt
#0  0x00007f1a91b10103 in memcpy () from /lib/libc.so.6
#1  0x0000000000402dee in packet_callback (user=0x0, header=0x7ffff3e0c8a0, 
packet=0x7f1a755ad046 <Address 0x7f1a755ad046 out of bounds>) at execap.c:684
#2  0x00007f1a92043d58 in pcap_read_linux_mmap () from /usr/lib/libpcap.so.1
#3  0x00007f1a920495c9 in pcap_loop () from /usr/lib/libpcap.so.1
#4  0x0000000000401698 in main () at execap.c:250
(gdb)

Original comment by bmenr...@ucsd.edu on 18 Jan 2011 at 9:15

GoogleCodeExporter commented 9 years ago 
(gdb) up
#1  0x0000000000402dee in packet_callback (user=0x0, header=0x7ffff3e0c8a0, 
packet=0x7f1a755ad046 <Address 0x7f1a755ad046 out of bounds>) at execap.c:684
684             memcpy((*pp_working_packet)->data + 
(*pp_working_packet)->datalen,
(gdb) list
679                                                  
(((*pp_working_packet)->datalen +
680                                                    
(*pp_next_packet)->datalen) -
681                                                   overlap));
682
683             /* We need to copy the new data in */
684             memcpy((*pp_working_packet)->data + 
(*pp_working_packet)->datalen,
685                    (*pp_next_packet)->data + overlap,
686                    (*pp_next_packet)->datalen - overlap);
687
688             /* We need to record this new size */

Original comment by bmenr...@ucsd.edu on 18 Jan 2011 at 9:15

GoogleCodeExporter commented 9 years ago 
It seems (*pp_working_packet)->data is a null pointer.  I'll look into it.

(gdb) p overlap
$3 = 571
(gdb) p (*pp_next_packet)->datalen
$4 = 556
(gdb) p (*pp_working_packet)->data
$5 = (u_char *) 0x0
(gdb) p (*pp_next_packet)->data
$6 = (u_char *) 0x786d480 "5\001"
(gdb) p (*pp_working_packet)->datalen
$7 = 15

Original comment by bmenr...@ucsd.edu on 18 Jan 2011 at 9:46

GoogleCodeExporter commented 9 years ago 
Well two issues.  First I didn't check the return call to realloc() so this 
could have been handled gracefully.  Second, my realloc() size computation 
yielded a value of 0 which allows realloc() to return a null pointer:

(gdb) p (((*pp_working_packet)->datalen + (*pp_next_packet)->datalen) - overlap)
$8 = 0

I will fix this shortly.

Original comment by bmenr...@ucsd.edu on 18 Jan 2011 at 9:47

GoogleCodeExporter commented 9 years ago 
While the code that is crashing needs to check the conditions better, the bug 
is located elsewhere.

The linked-list is out of order:

(gdb) p (*pp_next_packet)->seq
$12 = 3865915733

(gdb) p (*pp_working_packet)->seq
$13 = 3865916289

This is not supposed to happen.  The code assumes that the packets are in-order 
and they are supposed to be inserted in-order.  I will add an out-of-order 
check and try to figure out how this is happening.

Original comment by bmenr...@ucsd.edu on 18 Jan 2011 at 11:11

GoogleCodeExporter commented 9 years ago 
I fixed this issue in commit 4 with this check-in comment:

"Fixed issue 19.  The problem had to do with the sequence comparisons
being correct for the start of a packet but incorrect for the end of
the packet.  This happened because the packets being compared were at
opposite halves of the sequence space, separated by 2^31 bytes.  I
added code to make sure that the sequences being compared aren't too
far away from each other.  Right now "too far away" is set to 32 MB."

Essentially code that was crashing required packets to be in-order in the list 
but the code that handled inserting them could mistakenly insert them 
out-of-order because the 32-bit sequence address space wraps and if two packets 
are separated by 2^31 bytes the checks would not be valid.  Now the code just 
abandons connections with packets that are too far away from each other.

Original comment by bmenr...@ucsd.edu on 23 Jan 2011 at 3:14