Wireshark-dev: Re: [Wireshark-dev] Ideas regarding bug 1025?

From: Neil Piercy <Neil.Piercy@xxxxxxxxxxxx>
Date: Fri, 04 Aug 2006 12:56:11 +0100

I did a little more investigation on this:

The crash only happens trying to display the response packets in the bug trace - handling the request packets is fine, and both go through the same execution path in this area. The big difference between the request and the response is that the _values_ of the 64 bit monotonic replay detection counter: the requests use very small values, the responses use huge values (i.e. all bytes of the 64 bit values are non-zero).

The crash definitely happens deep in the glib handling of the g_vsnprintf - I dont have a debug build of glib, but it looked like it went into the guts of the core gnulib/vasnprintf, where it hit an abort call. Without the debug lib it is difficult to see where or why.

Bottom line: looks to me like a glib bug or a build incompatibility between guint64 handling in the glib binary and ethereal perhaps?

Neil

Neil Piercy wrote:

Hi,

The head of the stack just before the exception is given below.

The actual error is in proto_tree_set_representation at the call:
	g_vsnprintf(fi->rep->representation, ITEM_LABEL_LENGTH, format, ap);

The format has a single %I64x value needed.

The entry to the routine throws an MSVC Runtime Library error dialogue.

Not an area I know much about, but I can reproduce it - if this isnt ringing any bells, drop me a line with where to look next, and I'll give it a whirl.

Neil

proto_tree_set_representation(_proto_node * 0x02d6e418, const char * 0x01489ad8, char * 0x0012e378) line 2938 proto_tree_add_text(_proto_node * 0x02d6e4d8, tvbuff * 0x02cfba9c, int 323, int 8, const char * 0x01489ad8) line 677 + 17 bytes bootp_option(tvbuff * 0x02cfba9c, _proto_node * 0x02cfb020, int 318, int 376, int 0, int * 0x0012e478, const char * * 0x0012e488, const unsigned char * * 0x0012e454) line 1211 + 42 bytes dissect_bootp(tvbuff * 0x02cfba9c, _packet_info * 0x02c1cef8, _proto_node * 0x02cfb5c0) line 3162 + 35 bytes call_dissector_through_handle(dissector_handle * 0x02abd640, tvbuff * 0x02cfba9c, _packet_info * 0x02c1cef8, _proto_node * 0x02cfb5c0) line 387 + 18 bytes

Joerg Mayer wrote:

Hello,

On Linux, I can't reproduce the crash mentioned in
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1025
Can someone please try to test this on Windows and maybe provide a stack
trace?

Thanks
    Joerg

--
=================================================
ip.access ltd                   Tel: 01954 713715
Building 2020,                  Fax: 01954 713799
Cambourne Business Park,
Cambourne,
Cambridge, CB3 6DW, UK
Visit the website at http://www.ipaccess.com
=================================================