Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Systematic crash at startup when launching Wireshark GTK+ 1.

From: Pascal Quantin <pascal.quantin@xxxxxxxxx>
Date: Mon, 15 Sep 2014 19:02:37 +0200


Le 15 sept. 2014 18:27, "Gerald Combs" <gerald@xxxxxxxxxxxxx> a écrit :
>
> On 9/14/14 1:34 PM, Pascal Quantin wrote:
> > Hi all,
> >
> > I just installed a new Windows 8.1 x64 computer and each time I launch
> > the GTK2 GUI of master branch, I get a silent crash.
> > After generating a memory dump and loading it in windbg, I could see
> > that it crashes in gtk_init call:
> > (1d90.1998): Access violation - code c0000005 (first/second chance not
> > available)
> > *** ERROR: Symbol file could not be found.  Defaulted to export symbols
> > for KERNELBASE.dll -
> > ntdll!ZwWaitForMultipleObjects+0xa:
> > 00007ffc`67b61c2a c3              ret
> > 0:000> .ecxr
> > *** ERROR: Symbol file could not be found.  Defaulted to export symbols
> > for libgobject-2.0-0.dll -
> > rax=000000d4111b9000 rbx=00000000111c6590 rcx=000000d4111b9000
> > rdx=0000000000000000 rsi=0000000000000020 rdi=0000000000000048
> > rip=000000005949562b rsp=000000d40f56efe0 rbp=000000d4111c9a80
> >  r8=0000000000000000  r9=0000000000000003 r10=0000000000000000
> > r11=00007ffc674e1725 r12=0000000000000020 r13=0000000000000048
> > r14=000000d40f8de318 r15=000000d4111c9c60
> > iopl=0         nv up ei pl nz na pe nc
> > cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b
> > efl=00010202
> > libgobject_2_0_0!g_type_create_instance+0x15b:
> > 00000000`5949562b 0fb67b14        movzx   edi,byte ptr [rbx+14h]
> > ds:00000000`111c65a4=??
> >
> > The corresponding call stack is:
> > libgobject_2_0_0!g_type_create_instance+0x15b
> > libgobject_2_0_0!g_param_spec_internal+0x146
> > libgobject_2_0_0!g_param_spec_object+0x77
> > libgdk_win32_2_0_0!gdk_pointer_is_grabbed+0x123
> > libgobject_2_0_0!g_type_class_ref+0x4a7
> > libgobject_2_0_0!g_object_newv+0x26e
> > libgobject_2_0_0!g_object_new+0x72
> > libgdk_win32_2_0_0!gdk_display_manager_get+0x24
> > libgtk_win32_2_0_0!gtk_misc_get_padding+0xdd3
> > libgtk_win32_2_0_0!gtk_list_store_insert_with_valuesv+0x101c
> > libglib_2_0_0!g_option_context_parse+0x3a7
> > libgtk_win32_2_0_0!gtk_parse_args+0x7b
> > libgtk_win32_2_0_0!gtk_init_check+0x9
> > libgtk_win32_2_0_0!gtk_init+0x9
> > Wireshark_gtk!main(int argc = 0n1, char ** argv = 0x000000d4`0f630540)+0x612
> > Wireshark_gtk!WinMain(struct HINSTANCE__ * hInstance =
> > 0x00007ff7`ac530000, struct HINSTANCE__ * hPrevInstance =
> > 0x00000000`00000000, char * lpszCmdLine = 0x000000d4`0f612e8f "", int
> > nCmdShow = 0n1)+0x7e
> > Wireshark_gtk!__tmainCRTStartup(void)+0x149
> > kernel32!BaseThreadInitThunk+0xd
> > ntdll!RtlUserThreadStart+0x1d
> >
> > After doing a bisection, I noticed that it started appearing when we
> > switched to GTK+ 2.24.23:
> > commit 0a249087c311feacf693144372ec038938c47415
> > Author: Gerald Combs <gerald@xxxxxxxxxxxxx <mailto:gerald@xxxxxxxxxxxxx>>
> > Date:   Fri May 16 09:21:57 2014 -0700
> >
> >     Build with GTK+ 2.24.23.
> >
> >     Change-Id: Ic5c385c0fcef4d40a8cb9e7a271d14eb80905460
> >     Reviewed-on: https://code.wireshark.org/review/1665
> >     Reviewed-by: Gerald Combs <gerald@xxxxxxxxxxxxx
> > <mailto:gerald@xxxxxxxxxxxxx>>
> >     Tested-by: Gerald Combs <gerald@xxxxxxxxxxxxx
> > <mailto:gerald@xxxxxxxxxxxxx>>
> >
> > But at the same time 1.12.0 release uses the same GTK2 package and works
> > fine, so I'm puzzled. the amster x86 package works fine.
> >
> > I tried upgrading the GTK2 package thanks to the download-mingw-rpm.py
> > but the latest packages from OpenSUSE seem to lack some libraries.
> >
> > I'm a bit out of ideas for now. Anyone familiar with this kind of issues?
>
> I can duplicate the problem here. If I create a package by hand using
> Visual C++ 2010 Wireshark-gtk.exe runs fine.

It explains why it works fine with 1.12.0 then... And why I could not figure out a major difference in main.c file explaining the behavior while using the same libraries!