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 ================================================= _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
