[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <11911.1175195819@redhat.com>
Date: Thu, 29 Mar 2007 20:16:59 +0100
From: David Howells <dhowells@...hat.com>
To: Pavel Machek <pavel@....cz>
Cc: "Kawai, Hidehiro" <hidehiro.kawai.ez@...achi.com>,
Andrew Morton <akpm@...ux-foundation.org>,
kernel list <linux-kernel@...r.kernel.org>,
Robin Holt <holt@....com>, Alan Cox <alan@...rguk.ukuu.org.uk>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
sugita <yumiko.sugita.yf@...achi.com>,
Satoshi OSHIMA <soshima@...hat.com>,
Hideo AOKI <haoki@...hat.com>, dhowells@...hat.com
Subject: Re: [PATCH 1/4] coredump: add an interface to control the core dump routine
Pavel Machek <pavel@....cz> wrote:
> > Userland core dumper is useful because it is relatively easy to be
> > customized, but its reliability highly depends on the application
> > programs.
>
> Fix userland core dumper to be reliable, then.
I don't think it's that easy. The userland core dumper, as I understand it,
has to work *within* an application program (it's a library), thus the
application program my scotch the core dumper in a couple of ways:
(1) by trying to claim the same services (such as signal handlers).
(2) by destroying the coredumper should the application run amok and splat it
(by munmapping it, mmapping over it, writing over it, etc.).
Plus there are cases that an in-application userspace coredumper can't catch -
namely double/triple faults.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists