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] stable release 1.6.1 is core dumped on Fedora 13, 15

From: Graham Bloice <graham.bloice@xxxxxxxxxxxxx>
Date: Fri, 05 Aug 2011 10:38:56 +0100
On 04/08/2011 20:23, Guy Harris wrote:
> On Aug 4, 2011, at 10:47 AM, Roland Knall wrote:
>
>> There should be a file called core in the directory you called Wireshark from. Please send this file.
> More precisely, "please send this file, and the entire build directory for Wireshark, to somebody also running the same version of Fedora".  Core dumps can't really be interpreted without the executable image that produced them and all the dynamically-loaded libraries (and, if the crash occurred in a run-time-loaded plugin, the plugin in question), including system libraries, it was using at the time - and at least some symbols are needed as well.
>
> An alternative would be to run the debugger (gdb, probably) on the core dump and run the command to print a stack trace ("backtrace" or "bt", for gdb) and send us the stack trace.
>
Interesting info, to me anyway as I haven't done any serious debugging in *nix.

For general interest, the Windows world has a scheme to help in this sort of
situation using symbol servers.  If the pdb's (debug info) from a build are
added to a symbol server then the Windows version of a core dump, usually
called a crash dump but it can be generated for a hung app as well, can be
debugged on any Windows machine with full symbols automatically obtained from
the apps symbol server.  MS make symbols for all the Windows components
available for free as well.  An additional feature is source indexing which
adds source version control info into the pdb's so the debugger can also
retrieve the relevant source files.  There is no need to replicate the target
environment on the debuggers host machine.

IME this all works really well and in the day job allows us to fully debug app
crashes after the customer has sent us the crash dump.  The slight fly in the
ointment is that it's best to get a full memory crash dump which has all the
allocated process memory in it so they can be quite large, but do compress
reasonably well.

I have no idea if this would be generally useful for crash debugging wireshark
on Windows as I have no idea of the rate of problem reports.

-- 
Regards,

Graham Bloice