On Mon, Oct 02, 2000 at 03:10:10PM +0100, James Cownie wrote:
>
> > Queueing the tcores in the mm_struct could work though. Add a prctl [1]
> > that enables tcore core dumping. When tcore core dumping is enabled every
> > core dump that would dump a mm_struct with reference count > 1 does not
>
> Queueing the tcores in the mm_struct could work though. Add a prctl [1]
> that enables tcore core dumping. When tcore core dumping is enabled every
> core dump that would dump a mm_struct with reference count > 1 does not
> actually dump it, but just queues a structure (tqueue) with its
> Can someone explain why core dumping can't be done in userspace?
...
> There must be a good reason Unix and Linux don't do this ... but I
> haven't thought of it yet. Anyone care to enlighten me?
The problem, I believe, is that once a process has reached the point
where it has been delivered
Can someone explain why core dumping can't be done in userspace?
...
There must be a good reason Unix and Linux don't do this ... but I
haven't thought of it yet. Anyone care to enlighten me?
The problem, I believe, is that once a process has reached the point
where it has been delivered a
Queueing the tcores in the mm_struct could work though. Add a prctl [1]
that enables tcore core dumping. When tcore core dumping is enabled every
core dump that would dump a mm_struct with reference count 1 does not
actually dump it, but just queues a structure (tqueue) with its registers/
On Mon, Oct 02, 2000 at 03:10:10PM +0100, James Cownie wrote:
Queueing the tcores in the mm_struct could work though. Add a prctl [1]
that enables tcore core dumping. When tcore core dumping is enabled every
core dump that would dump a mm_struct with reference count 1 does not
actually
On Sat, Sep 30, 2000 at 03:07:57PM -0400, Alexander Viro wrote:
>
>
> On Sat, 30 Sep 2000, James Cownie wrote:
>
> > I was expecting to take the Posix thread style viewpoint in which any
> > of the core dumping signals kill the _process_, so all of the threads
> > are necessarily dead
On Sat, Sep 30, 2000 at 03:07:57PM -0400, Alexander Viro wrote:
On Sat, 30 Sep 2000, James Cownie wrote:
I was expecting to take the Posix thread style viewpoint in which any
of the core dumping signals kill the _process_, so all of the threads
are necessarily dead thereafter since
On Sat, 30 Sep 2000, James Cownie wrote:
> I was expecting to take the Posix thread style viewpoint in which any
> of the core dumping signals kill the _process_, so all of the threads
> are necessarily dead thereafter since they have nowhere to live any
> longer.
Different model. Threads are
On Sat, Sep 30, 2000 at 03:45:54PM +0100, James Cownie wrote:
> Since the Villarreal patch exists and seems to do all that I wanted, I
> don't propose to create a competing patch.
>
> Maybe you kernel gurus could point out any problems with the Villarreal
> approach ?
The patch assumes that
> Open question: whether or not to allow the remaining threads to
> continue once the dump is completed, to abort them, or to signal
> them. Probably should be run time configurable.
I was expecting to take the Posix thread style viewpoint in which any
of the core dumping signals kill the
Open question: whether or not to allow the remaining threads to
continue once the dump is completed, to abort them, or to signal
them. Probably should be run time configurable.
I was expecting to take the Posix thread style viewpoint in which any
of the core dumping signals kill the
On Sat, Sep 30, 2000 at 03:45:54PM +0100, James Cownie wrote:
Since the Villarreal patch exists and seems to do all that I wanted, I
don't propose to create a competing patch.
Maybe you kernel gurus could point out any problems with the Villarreal
approach ?
The patch assumes that all
> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 29, 2000 2:08 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Anyone working o
> -Original Message-
> From: Igmar Palsenberg [mailto:[EMAIL PROTECTED]]
[snip]
>
> Maybe I'm totally stupid, but I think you need to sync the
> threads so that
> the're in the same state. And I don't think it's that simple.
>
> Or I'm talking totally nonsense here :)
>
I think
On Fri, 29 Sep 2000, Alan Cox wrote:
> > > while the dump is taken? How about thread A coredumping, half of the image
> > > being already written and thread B (nowhere near the kernel mode, mind
> > > you) changing the data both in the area that is already dumped and area
> > > the still
> > while the dump is taken? How about thread A coredumping, half of the image
> > being already written and thread B (nowhere near the kernel mode, mind
> > you) changing the data both in the area that is already dumped and area
> > the still isn't? After that you can look at the dump and notice
Alexander Viro wrote:
> How about preventing the rest of threads from doing mmap()/munmap()/etc.
> while the dump is taken? How about thread A coredumping, half of the image
> being already written and thread B (nowhere near the kernel mode, mind
> you) changing the data both in the area that is
On Fri, 29 Sep 2000, Igmar Palsenberg wrote:
> > I was aiming at the simplest and in my mind most obvious thing, which
> > is to have the standard ELF coreer dump handle multiple threads in the
> > same way as it does on many other systems. The lack of these causes
> > shrieks of amazement
> I was aiming at the simplest and in my mind most obvious thing, which
> is to have the standard ELF coreer dump handle multiple threads in the
> same way as it does on many other systems. The lack of these causes
> shrieks of amazement from many of our customers :-(
>
> This is not rocket
On Fri, Sep 29, 2000 at 01:34:47PM +0100, James Cownie wrote:
>
> I was aiming at the simplest and in my mind most obvious thing, which
> is to have the standard ELF coreer dump handle multiple threads in the
> same way as it does on many other systems. The lack of these causes
> shrieks of
Richard Moore - RAS Project Lead - Linux Technology Centre.
wrote :-
> If you have ideas/concerns/requirements please make them known.
...
> There are many things we'd like to see
> incorporated, the question is how not to boil the ocean. Here are some of
> the ideas we are thinking about:
>
> The synchronization on dump between the processes sharing a VM is quite nasty
> actually. There were patches for it in the past, but they usually got that
> wrong. Linux has no way currently to stop them atomically.
How atomic does it need to be, though ?
In a uni-processor there shouldn't
Yes we (IBM Linux Technology Center RAS Team) are. If you have
ideas/concerns/requirements please make them known. We are at the point of
deciding what to attack. We have other dumping technologies on other OSs we
could model a Linux enhancement on. There are many things we'd like to see
On Fri, Sep 29, 2000 at 12:22:28PM +0100, James Cownie wrote:
>
> Please let me know (by mail) otherwise I may take a look, since it
> doesn't appear to be a _huge_ problem any longer, and it's one of the
> things users keep bitching at us about when using our debugger :-(
The synchronization
On Fri, Sep 29, 2000 at 12:22:28PM +0100, James Cownie wrote:
Please let me know (by mail) otherwise I may take a look, since it
doesn't appear to be a _huge_ problem any longer, and it's one of the
things users keep bitching at us about when using our debugger :-(
The synchronization on
Yes we (IBM Linux Technology Center RAS Team) are. If you have
ideas/concerns/requirements please make them known. We are at the point of
deciding what to attack. We have other dumping technologies on other OSs we
could model a Linux enhancement on. There are many things we'd like to see
Richard Moore - RAS Project Lead - Linux Technology Centre.
wrote :-
If you have ideas/concerns/requirements please make them known.
...
There are many things we'd like to see
incorporated, the question is how not to boil the ocean. Here are some of
the ideas we are thinking about:
The synchronization on dump between the processes sharing a VM is quite nasty
actually. There were patches for it in the past, but they usually got that
wrong. Linux has no way currently to stop them atomically.
How atomic does it need to be, though ?
In a uni-processor there shouldn't be
On Fri, Sep 29, 2000 at 01:34:47PM +0100, James Cownie wrote:
I was aiming at the simplest and in my mind most obvious thing, which
is to have the standard ELF coreer dump handle multiple threads in the
same way as it does on many other systems. The lack of these causes
shrieks of amazement
I was aiming at the simplest and in my mind most obvious thing, which
is to have the standard ELF coreer dump handle multiple threads in the
same way as it does on many other systems. The lack of these causes
shrieks of amazement from many of our customers :-(
This is not rocket science,
On Fri, 29 Sep 2000, Igmar Palsenberg wrote:
I was aiming at the simplest and in my mind most obvious thing, which
is to have the standard ELF coreer dump handle multiple threads in the
same way as it does on many other systems. The lack of these causes
shrieks of amazement from many
Alexander Viro wrote:
How about preventing the rest of threads from doing mmap()/munmap()/etc.
while the dump is taken? How about thread A coredumping, half of the image
being already written and thread B (nowhere near the kernel mode, mind
you) changing the data both in the area that is
while the dump is taken? How about thread A coredumping, half of the image
being already written and thread B (nowhere near the kernel mode, mind
you) changing the data both in the area that is already dumped and area
the still isn't? After that you can look at the dump and notice
On Fri, 29 Sep 2000, Alan Cox wrote:
while the dump is taken? How about thread A coredumping, half of the image
being already written and thread B (nowhere near the kernel mode, mind
you) changing the data both in the area that is already dumped and area
the still isn't? After that
-Original Message-
From: Igmar Palsenberg [mailto:[EMAIL PROTECTED]]
[snip]
Maybe I'm totally stupid, but I think you need to sync the
threads so that
the're in the same state. And I don't think it's that simple.
Or I'm talking totally nonsense here :)
I think one needs
-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 29, 2000 2:08 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Anyone working on multi-threaded core files
37 matches
Mail list logo
