Messages in this thread |  | | Subject | Re: Anyone working on multi-threaded core files for 2.4 ? | Date | Mon, 02 Oct 2000 15:10:10 +0100 | From | James Cownie <> |
| |
> 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/
|  |