mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Don Dugger <n0ano@valinux.com>
To: Szabolcs Szakacsits <szaka@f-secure.com>
Cc: Don Dugger <n0ano@valinux.com>,
	Linus Torvalds <torvalds@transmeta.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Thread core dumps for 2.4.4
Date: Mon, 7 May 2001 09:54:15 -0600	[thread overview]
Message-ID: <20010507095415.A3716@tlaloc.n0ano.com> (raw)
In-Reply-To: <20010503085418.A12123@tlaloc.n0ano.com> <Pine.LNX.4.30.0105061833220.16238-100000@fs131-224.f-secure.com>
In-Reply-To: <Pine.LNX.4.30.0105061833220.16238-100000@fs131-224.f-secure.com>; from szaka@f-secure.com on Sun, May 06, 2001 at 06:47:28PM +0200

Szaka-

I would considier what you're suggesting to be a refinement on this
patch.  The first problem is to generate valid core dumps for all
threads.  Adding in policy decisions about which threads actually
generate core files can be done later.

Adam ? (I'm sorry, I've lost the mail with his full name) actually
posted a patch a while back that only dumped core for the first
faulting thread.  The problem with this patch is that it didn't
deal with the potential races between threads modifying the memory
maps while the core dump was being generated.  Also, this patch used
a single system wide variable to make its policy decisions, this
really needs to be a per-process decision.

What I'd really like to see is some sort of rondezous capability where,
when a fatal exception occurs, all the threads are halted, appropriate
core dumps are generated, and then all the threads are resumed (to
terminate or continue as appropriate).  This is a bigger project that
will require a little thought.

On Sun, May 06, 2001 at 06:47:28PM +0200, Szabolcs Szakacsits wrote:
> 
> On Thu, 3 May 2001, Don Dugger wrote:
> 
> > The attached patch allows core dumps from thread processes in the 2.4.4
> > kernel.  This patch is the same as the last one I sent out except it fixes
> > the same bug that `kernel/fork.c' had with duplicate info in the `mm'
> > structure, plus this patch has had more extensive testing.
> 
> AFAIK Linux can't dump the threads to the same file as others but doing
> it to different files looks a bit scary. How the system behaves when you
> dump a heavy threaded app with a decent VM [i.e just think about a
> bloatware instead of malicious code]? How will the developer know which
> thread caused the fault? I've found dumping just the faulting thread is
> enough about 100% of the cases especially because [on SMP] others can
> run on and the dump is much more close to "garbage" then usuful info
> from a debug point of view.
> 
> 	Szaka

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@valinux.com
Ph: 303/938-9838

      parent reply	other threads:[~2001-05-07 15:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-03 14:54 Don Dugger
2001-05-06 16:47 ` Szabolcs Szakacsits
2001-05-07 15:22   ` Zdenek Kabelac
2001-05-07 15:54   ` Don Dugger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010507095415.A3716@tlaloc.n0ano.com \
    --to=n0ano@valinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=szaka@f-secure.com \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®