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 registe
> 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
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 thereafte
[James Cownie]
> I was thinking that a scheme in which the core-dumping thread hit all
> the others with a SIGSTOP and then (somehow...) waited for them all
> to stop before writing the core file would suffice. (Of course, I may
> be wrong !)
Can someone explain why core dumping can't be done in
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 all
> 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 _proc
> -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
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?
> > 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 from
> 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 sci
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 amaze
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 b
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
incorp
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
20 matches
Mail list logo
