Hi List!
I was reporting an access violation in the
Analyze->Statistics->Conversation List functions some while ago, but
noone could reproduce this bug.
The access violation is always at the same point while running it, but
is dependant on the capture file I have opened,
so it has to do something with the packets captured.
A capture file which is ok, is always ok, a capture file which fails
will always fail, so it's no transient bug :-)
The access violation is always in endpoint_talkers_tcpip.c line 51
(or the similar line in the other endpoint_talkers_xy sourcefiles,
depending on the function called):
add_ett_table_data(talkers, &tcphdr->ip_src, &tcphdr->ip_dst,
tcphdr->th_sport, tcphdr->th_dport, 1, pinfo->fd->pkt_len, SAT_NONE,
PT_TCP);
As the pinfo->fd is 0x15, the pinfo->fd->pkt_len is doing the access
violation.
The callstack is looking like this:
tcpip_talkers_packet(void * 0x021e1cb0, _packet_info * 0x021a3520,
_epan_dissect_t * 0x021a3518, void * 0x00c21880) line 51 + 10 bytes
tap_push_tapped_queue(_epan_dissect_t * 0x021a3518) line 263 + 31 bytes
retap_packet(_capture_file * 0x00c36b40, _frame_data * 0x02050f58,
wtap_pseudo_header * 0x0011ed44, const unsigned char * 0x0011edd4, void
* 0x00000000) line 1413 + 9 bytes
process_specified_packets(_capture_file * 0x00c36b40, packet_range_tag *
0x0012ee24, const char * 0x00bc5310, const char * 0x00bc5304, int
(_capture_file *, _frame_data *, wtap_pseudo_header *, const unsigned
char *, void *)* 0x00727ae7 retap_packet(_capture_file *, _frame_data *,
wtap_pseudo_header *, const unsigned char *, void *), void * 0x00000000)
line 1385 + 29 bytes
retap_packets(_capture_file * 0x00c36b40) line 1433 + 33 bytes
init_ett_table(int 0, char * 0x00c01ea0, char * 0x00c01e9c, char *
0x00000000, void * 0x007cc365 tcpip_talkers_packet(void *, _packet_info
*, _epan_dissect_t *, void *)) line 1071 + 10 bytes
gtk_tcpip_talkers_init(char * 0x00c01e84) line 69 + 26 bytes
gtk_tcpip_endpoints_cb(_GtkWidget * 0x01ae6eb0, void * 0x00000000) line
77 + 10 bytes
LIBGTK-WIN32-2.0-0! 00e006a8()
LIBGOBJECT-2.0-0! 00fb7ae9()
Attached is a capture file which is causing this bug.
Could someone take a look at this, as I have not enough knowledge of the
conversation stuff to debug this myself.
Regards, ULFL
Attachment:
testserver2.cap
Description: Binary data