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
=================================================
