Re: Debugging coredumps in different computers

[Paul Pluzhnikov]

"Bruno Gonzalez (STenyaK)" <stenyak@gmail.com> writes:

>> Without matching shared libraries, gdb just uses whatever libraries
>> are installed on the current system, if these don't match what's
>> in the dump, you get "garbage".
>
> I see, thanks for the info. Unfortunately, that increases the crash
> information a lot. My idea was to have user coredumps sent to me
> automatically, so that i can debug them.

Well, if you collect package/version info for all the DSOs in
the process, you probably can fetch corresponding packages,
and debug that core.

Obviously you wouldn't be able to do that for "self-built"
libraries. Depending on who your users are, this may be quite rare,
or quite frequent.

Also, often you could just ask the user to run gdb (or even do that
automatically), and just send gdb output instead of core. You'll
likely be interested in "info threads", "thread apply all where",
"thread apply all locals", and "thread apply all info reg".

> Is there any way to create something similar to Windows minidumps?

Windows minidumps only work because there is a single place
(Microsoft) where you can get .PDB for every version of every
"system" library ever distributed. AFAIK, you can't debug windows
minidump (at least not with symbolic function names), unless you
have access to microsoft symbol server (or have the correct .PDBs
cached locally).

> Some way to make the coredumps smaller somehow?

bzip2 ?

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.