Hello,
Can I get a copy of your patch, too?
On Thu, 15 Mar 2001 [EMAIL PROTECTED] wrote:
>
> >
> >(I have a complimentary hack that will dump the stacks of all the
> >rest of the threads as well (though its a good trick to get gdb to
> >interpret this). Available upon request.)
> >
>
> Hello
> It does work, however. It effectively dumps the thread that caused the
> fault.
If you want that behavior, catch SIGSEGV, fork, and have the child
process (in which only the faulting thread exists) call abort.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
> On Sat, Feb 24, 2001 at 09:57:44PM +, Alan Cox wrote:
>
> The I/O to dump the core would race other changes on the mm. The
> right fix is probably to copy the mm (as fork does) then dump the
> copy.
>
> Stupid question... but since all threads see the same memory space as
> eac
Chris Wedgwood <[EMAIL PROTECTED]> writes:
> On Sat, Feb 24, 2001 at 09:57:44PM +, Alan Cox wrote:
>
> The I/O to dump the core would race other changes on the mm. The
> right fix is probably to copy the mm (as fork does) then dump the
> copy.
>
> Stupid question... but since al
Theres a patch floating around that does just that. Its an obvious
hack. I would like to see something clean get into the mainstream
kernels. Its a real pain not to have cores for threaded code.
It does work, however. It effectively dumps the thread that caused the
fault.
(I have a complime
> Can anyone explain why this test is in routine `do_coredump'
> in file `fs/exec.c' in the 2.4.0 kernel?
>
> if (!current->dumpable || atomic_read(¤t->mm->mm_users) != 1)
> goto fail;
>
> The only thing the test on `mm_users' seems to be doing is stopping
> a thread process from dumpi
6 matches
Mail list logo
