Ethereal-dev: [Ethereal-dev] Weird bug on MSVC build only (probably HTTP or tvb_get_ptr)
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: Biot Olivier <Olivier.Biot@xxxxxxxxxxx>
Date: Thu, 29 Apr 2004 19:59:23 +0200
Hi list, I have a (medium-sized) capture that only causes crashes on Win32 builds (not on cygwin builds) after a certain number of operations on the capture (like using the "decode as" option to match a given TCP stream to HTTP). Both builds have an identical source tree (cvs copy from this morning). Where Ethereal crashes depends on the order and type of operations I perform on the capture. I however invariably get the following information from a debug session: pinfo->fd->flags = 0 pinfo->ptype = 2 (TCP) pinfo->srcport = 80 pinfo->match_port = 80 pinfo->match_string = (null) pinfo->bytes_until_next_pdu = 1.869.426.276 (0x6F6D2E64) I strongly suspect the pinfo->bytes_until_next_pdu value (which is the same for some crashes, but I've also seen a value of 8) is the reason why I get the crash. It looks like it is being incorrectly set somewhere (maybe in TCP reassembly code?). I have all TCP options ticked except for the last (try heuristic dissectors first), and I have all HTTP and IP options ticked too. The packets where the error occurs are the last from a TCP reassembly for reassembling a HTTP response. If I inspect the last function from the stack, the debugger points at basic_response_dissector() in packet-http.c at the if statement: if (sscanf((const gchar *)data, "%d.%d %d", &minor, &major, &status_code) == 3) { If I inspect the value returned from the statement on the line before the if statement: data = tvb_get_ptr(tvb, 5, 12); then I don't get a 12-byte copy of the data but instead I get a pointer to the real data (which is much longer than the expected 12 bytes). So it looks like the sscanf() call reads past the allowed memory? This is somehow confirmed by the fact that the minor, major and status_code variables are not initialized. I also have to say that the reassembled data in the error packets always consists of very small fragments (sometimes less than 10 bytes). This is the stack trace of one of such errors: MSVCRT! 77c3e958() basic_response_dissector(tvbuff * 0x04344528, _proto_node * 0x02080fc0, int 10) line 790 + 27 bytes dissect_http_message(tvbuff * 0x04344528, int 0, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 496 + 15 bytes dissect_http(tvbuff * 0x04344528, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 1413 + 21 bytes call_dissector_through_handle(dissector_handle * 0x0172bfe8, tvbuff * 0x04344528, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 363 + 18 bytes call_dissector_work(dissector_handle * 0x0172bfe8, tvbuff * 0x04344528, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 513 + 21 bytes dissector_try_port(dissector_table * 0x01773208, unsigned int 80, tvbuff * 0x04344528, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 776 + 21 bytes decode_tcp_ports(tvbuff * 0x043444f4, int 0, _packet_info * 0x032ffb08, _proto_node * 0x02072df0, int 80, int 41451) line 2362 + 34 bytes process_tcp_payload(tvbuff * 0x043444f4, volatile int 0, _packet_info * 0x032ffb08, _proto_node * 0x02072df0, _proto_node * 0x022bf198, int 80, int 41451, unsigned int 0, unsigned int 0, int 0) line 2410 + 35 bytes desegment_tcp(tvbuff * 0x043444c0, _packet_info * 0x032ffb08, int 20, unsigned int 273, unsigned int 650, unsigned int 80, unsigned int 41451, _proto_node * 0x02072df0, _proto_node * 0x022bf198) line 1674 + 37 bytes dissect_tcp_payload(tvbuff * 0x043444c0, _packet_info * 0x032ffb08, int 20, unsigned int 273, unsigned int 650, unsigned int 80, unsigned int 41451, _proto_node * 0x02072df0, _proto_node * 0x022bf198) line 2481 + 41 bytes dissect_tcp(tvbuff * 0x043444c0, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 2892 + 69 bytes call_dissector_through_handle(dissector_handle * 0x017a1988, tvbuff * 0x043444c0, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 363 + 18 bytes call_dissector_work(dissector_handle * 0x017a1988, tvbuff * 0x043444c0, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 513 + 21 bytes dissector_try_port(dissector_table * 0x0172d168, unsigned int 6, tvbuff * 0x043444c0, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 776 + 21 bytes dissect_ip(tvbuff * 0x04344058, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 1098 + 33 bytes call_dissector_through_handle(dissector_handle * 0x0172d2a0, tvbuff * 0x04344058, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 363 + 18 bytes call_dissector_work(dissector_handle * 0x0172d2a0, tvbuff * 0x04344058, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 513 + 21 bytes dissector_try_port(dissector_table * 0x016ff3f0, unsigned int 2048, tvbuff * 0x04344058, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 776 + 21 bytes ethertype(unsigned short 2048, tvbuff * 0x04344024, int 14, _packet_info * 0x032ffb08, _proto_node * 0x02072df0, _proto_node * 0x02295440, int 3336, int 3338, int 0) line 178 + 34 bytes dissect_eth_common(tvbuff * 0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0, int 0) line 293 + 48 bytes dissect_eth_maybefcs(tvbuff * 0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 387 + 26 bytes call_dissector_through_handle(dissector_handle * 0x01790568, tvbuff * 0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 363 + 18 bytes call_dissector_work(dissector_handle * 0x01790568, tvbuff * 0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 513 + 21 bytes dissector_try_port(dissector_table * 0x01709920, unsigned int 1, tvbuff * 0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 776 + 21 bytes dissect_frame(tvbuff * 0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 185 + 34 bytes call_dissector_through_handle(dissector_handle * 0x017099c8, tvbuff * 0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 363 + 18 bytes call_dissector_work(dissector_handle * 0x017099c8, tvbuff * 0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 513 + 21 bytes call_dissector(dissector_handle * 0x017099c8, tvbuff * 0x04344024, _packet_info * 0x032ffb08, _proto_node * 0x02072df0) line 1614 + 21 bytes dissect_packet(_epan_dissect_t * 0x032ffb00, wtap_pseudo_header * 0x00ccc428, const unsigned char * 0x00ccc4b8, _frame_data * 0x027a42f0, _column_info * 0x00cdc4cc) line 311 + 32 bytes epan_dissect_run(_epan_dissect_t * 0x032ffb00, void * 0x00ccc428, const unsigned char * 0x00ccc4b8, _frame_data * 0x027a42f0, _column_info * 0x00cdc4cc) line 153 + 25 bytes add_packet_to_packet_list(_frame_data * 0x027a42f0, _capture_file * 0x00ccc3a0, wtap_pseudo_header * 0x00ccc428, const unsigned char * 0x00ccc4b8, int 1) line 799 + 31 bytes rescan_packets(_capture_file * 0x00ccc3a0, const char * 0x00c59340, const char * 0x00c59334, int 1, int 1) line 1209 + 37 bytes redissect_packets(_capture_file * 0x00ccc3a0) line 1034 + 23 bytes decode_ok_cb(_GtkWidget * 0x01ffaa90, void * 0x030fcae8) line 802 + 10 bytes Anyone a clue? Regards, Olivier
- Follow-Ups:
- Prev by Date: [Ethereal-dev] Variable main GUI layout now implemented
- Next by Date: [Ethereal-dev] Re: GUI layout preference, 1st proposal
- Previous by thread: [Ethereal-dev] Variable main GUI layout now implemented
- Next by thread: Re: [Ethereal-dev] Weird bug on MSVC build only (probably HTTP ortvb_get_ptr)
- Index(es):