Re: [Wireshark-dev] Ideas regarding bug 1025?
Hi, The GTK and Glib packages where obtained from: http://www.gimp.org/~tml/gimp/win32/downloads.html it might be worth trying a newer version to see if the problem has been resolved (or check the release notes). Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Neil Piercy Skickat: den 10 augusti 2006 20:01 Till: Joerg Mayer Kopia: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Ideas regarding bug 1025? Joerg Mayer wrote: OK, I've created a small testprogram (under Suse 10.1) which you should compile as similar as possible to the way you compile Wireshark. Let's see whether it crashes and if so, where. I hope the program doesn't much tweaking to compile on W32. Worse than you feared: it crashes on test2 (in exactly the same manner as the whole wireshark app does with the test capture, so the test looks valid) - i.e. as soon as the upper 32 bits are non-zero. I'm trying to build a debug version of the glib-2.6.6 from original source, but its a bit painful - does anyone know the exact source (including config) that the distributed glib dll was built from ? Neil ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Ideas regarding bug 1025?
On Fri, Aug 04, 2006 at 12:56:11PM +0100, Neil Piercy wrote:
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).
Nice find! It has MSB set.
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?
OK, I've created a small testprogram (under Suse 10.1) which you should
compile as similar as possible to the way you compile Wireshark. Let's
see whether it crashes and if so, where. I hope the program doesn't much
tweaking to compile on W32.
ciao
Joerg
--
Joerg Mayer [EMAIL PROTECTED]
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
/* Testprogram for http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1025
*
* Compile with:
* gcc -Wall `pkg-config --cflags glib-2.0` `pkg-config --libs glib-2.0` -o
gtest64 gtest64.c
* which expands on my system to
* gcc -Wall -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include
-L/opt/gnome/lib -lglib-2.0 -o gtest64 gtest64.c
* Finally, run with ./gtest64 or something like that.
*/
#include glib.h
#include glib/gprintf.h
/* Formats for printing 64-bit unsigned hexadecimal numbers */
#ifndef PRIx64
#ifdef _MSC_EXTENSIONS
#define PRIx64 I64x
#else /* _MSC_EXTENSIONS */
#define PRIx64 llx
#endif /* _MSC_EXTENSIONS */
#endif /* PRIx64 */
#define BUFLEN 100
char buffer[BUFLEN];
guint64 test1 = G_GINT64_CONSTANT(0x11223344U);
guint64 test2 = G_GINT64_CONSTANT(0x11223344556677U);
guint64 test3 = G_GINT64_CONSTANT(0x1122334455667788U);
guint64 test4 = G_GINT64_CONSTANT(0xFFEEDDCC11223344U);
void
printit(const char *format, ...)
{
va_list ap;
va_start(ap, format);
g_vsnprintf(buffer, BUFLEN, format, ap);
g_printf(%s\n, buffer);
va_end(ap);
}
int main() {
printit(Test1: % PRIx64 , test1);
printit(Test2: % PRIx64 , test2);
printit(Test3: % PRIx64 , test3);
printit(Test4: % PRIx64 , test4);
return 0;
}
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Ideas regarding bug 1025?
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
Re: [Wireshark-dev] Ideas regarding bug 1025?
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
