> 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/
> signal info/etc. into a list in the mm_struct. When a thread dumps and
> the mm_struct count is 1 then dump a normal core file with all the tcores
> as thread notes. Also clean up all the cores then when freeing the mm_struct.
What is your model for the scope of this prctl ?
Should it be on a per-thread (OK, Alexander, "per process sharing the
same MM") basis, or does it apply to all members of the thread_group ?
It seems to me that it makes no sense unless
1) it applies to all members of the thread_group
(because without this the ref count on the mm will never get to
zero).
2) if it applies we also ensure that core dump signals get sent to all
members of the thread_group.
(because without this the other threads won't exit).
At the moment (test9-pre7) there seems to be no code in the kernel to
cause the core dumping signals to be fanned out. But then there seems
to be no code to cause any signals (even the negative "deliver to
thread group" ones) to be fanned out. I assume that's because it's
still work in progress.
(Yes, I know that linuxthreads does it from outside the kernel, but I
was under the impression that the aim of the thread_group was to make
it work better, and if we're going to do multi-threaded core files it
seems that distributing the core dumping signals inside the kernel
is essential).
Just to reiterate what I and, I think, some of the other folks who've
written the existing patches are trying to achieve :-
1) We want to provide multi-threaded core files for pthread programs,
where the user _expects_ a core dump signal to terminate all of the
threads in the process and the process itself as soon "as
possible".
2) We don't want to affect programs which are using the full linux
threads model. If it makes no sense to attempt to write a
multi-threaded core dump from such a process that's fine. People who
are using this model probably don't want such a thing anyway.
The "itch" I'm trying to scratch is the complaints we get from our
customers saying that our debugger doesn't work because it won't
provide them with any useful information from the core files they get
from their pthreaded codes when running on Linux. I don't like having
to explain that it's a kernel "feature" :-( so I'm trying to fix it
(or, at least, help other people to do do).
-- Jim
James Cownie <jcownie@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:09 EST