I'm looking for a way to generate smaller coredumps.  Essentially, I'd
like to capture things like the current registers, stack, thread and
process information, etc, similar to a Windows minidump.  I'd like to
then be able to run this through GDB with the associated symbolic
information and obtain some basic information about the process.  This
will be part of an automated crash reporting and analysis tool, hence
the interest in a smaller version of a coredump.  Windows can do this
with Minidumps, and in the interest of cross-platform compatibility I'm
wondering if there's anything similar on Unix?

[ Post a follow-up to this message ]

stephen.fedele@yale.edu writes:

> I'm looking for a way to generate smaller coredumps.  Essentially, I'd
> like to capture things like the current registers, stack, thread and
> process information, etc, similar to a Windows minidump.  I'd like to
> then be able to run this through GDB with the associated symbolic
> information and obtain some basic information about the process.  This
> will be part of an automated crash reporting and analysis tool, hence
> the interest in a smaller version of a coredump.  Windows can do this
> with Minidumps, and in the interest of cross-platform compatibility I'm
> wondering if there's anything similar on Unix?

Well, you can set the maximum coredump size using a shell command to
prevent HUGE core dumps. I'm not sure how usable they are, but
they are smaller.
(see csh's limit command)

You can also trap some of the errors and write out stuff yourself when
an error occurs. You can trap signals like SIGBUS, SIGSEGV and print
stuff out.


--
Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.

[ Post a follow-up to this message ]

stephen.fedele@yale.edu writes:

> I'm looking for a way to generate smaller coredumps.  Essentially, I'd
> like to capture things like the current registers, stack, thread and
> process information, etc, similar to a Windows minidump.  I'd like to
> then be able to run this through GDB with the associated symbolic
> information and obtain some basic information about the process.

One problem with this approach is that UNIX core dumps are generally
of very little use on any machine other then the one they were
generated on.

To analyze a core (e.g. to print crash stack trace), you need all
the libraries that match execution machine exactly, and you are
unlikely to have such a set of libraries for any given user machine.

> Windows can do this with Minidumps,

I have not looked into the format of Win32 minidumps, but believe
you can only effectively analyze them if you have access to matching
.PDB files. The fact that many DLLs come from a single vendor,
and that this vendor allows you to access .PDB for most of the
versions of DLLs they distribute, helps. But there is nothing even
remotely close on UNIX.

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

[ Post a follow-up to this message ]

stephen.fedele@yale.edu wrote:
> I'm looking for a way to generate smaller coredumps.  Essentially, I'd
> like to capture things like the current registers, stack, thread and
> process information, etc, similar to a Windows minidump.  I'd like to
> then be able to run this through GDB with the associated symbolic
> information and obtain some basic information about the process.  This
> will be part of an automated crash reporting and analysis tool, hence
> the interest in a smaller version of a coredump.  Windows can do this
> with Minidumps, and in the interest of cross-platform compatibility I'm
> wondering if there's anything similar on Unix?

You can catch SIGSEGV, SIGFAULT, and the like. In the signal handler,
you can dump whatever information you want. You can access the stack
with various gcc builtins (google around, getting the stack information
from a running program is a FAQ).

DS

[ Post a follow-up to this message ]

davids@webmaster.com writes:

> You can catch SIGSEGV, SIGFAULT, and the like. In the signal handler,
> you can dump whatever information you want.

In a signal handler, you pretty much can't do *anything* reliably.

> You can access the stack with various gcc builtins

Which, if stack is corrupted, will themselves promptly crash,
causing the failure to become even harder to diagnose.

While this approach may work sometimes in single-threaded
environment, it will be a complete failure if used as a general
diagnostic tool.

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

[ Post a follow-up to this message ]

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:

>One problem with this approach is that UNIX core dumps are generally
>of very little use on any machine other then the one they were
>generated on.

Which is why Solaris allows you to dump anything, including the
text segments.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

Casper H.S. Dik wrote On 06/07/06 01:21,:
> Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:
>
> 
>
>
> Which is why Solaris allows you to dump anything, including the
> text segments.

.. and if you're running Solaris 10, you've got
DTrace.  One of my colleagues used DTrace to build a
crash-catching tool that seems a pretty good match for
what the O.P. seeks.  Google for "appcrash".

--
Eric.Sosman@sun.com

[ Post a follow-up to this message ]

Bruce Barnett wrote:
> stephen.fedele@yale.edu writes: 
> prevent HUGE core dumps.

They are not as big as an "ls" connotes. As a sparse file, the actual
disk space used is much less than this number.

SOME tar(1) versions and all dump(1) versions can consign these
files to digital purgatory.

> (see csh's limit command)

or ulimit:

ulimit -hc 10k # whatever minidump-like limit is appropriate or
common...

=Brian

[ Post a follow-up to this message ]

Paul Pluzhnikov wrote:
> davids@webmaster.com writes:
> 
>
> In a signal handler, you pretty much can't do *anything* reliably.

Reliability is not important here, the program has already failed.
 
[vbcol=seagreen]
> Which, if stack is corrupted, will themselves promptly crash,
> causing the failure to become even harder to diagnose.

No problem, just 'fork' before you do it. That way, if one diagnostic
cannot complete, you can still do others.

> While this approach may work sometimes in single-threaded
> environment, it will be a complete failure if used as a general
> diagnostic tool.

I don't agree at all. It does take some effort to get it to work, but
it can be refined to the point where it's an extremely useful
diagnostic tool.

DS

[ Post a follow-up to this message ]

davids@webmaster.com writes:

> Reliability is not important here, the program has already failed.

Reliability *is* somewhat important here:
you may not see that same crash again for another year, so it might
be important to provide reliable crash trace.
 
> 
>
> No problem, just 'fork' before you do it.

fork()ing MT apps is surprizingly complicated, and subject to its
own set of crashes and deadlocks. If you crash or deadlock while
attempting to fork(), you loose all chances to provide any meaningful
results, and on some systems you get into a state where the process
can't even be killed with SIGKILL 
 
>
> I don't agree at all. It does take some effort to get it to work, but
> it can be refined to the point where it's an extremely useful
> diagnostic tool.

For a *specific* application, yes.

As a *general* toolkit, to be linked into *any*
application? Unlikely.

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

[ Post a follow-up to this message ]