Messages in this thread | | | Date | Wed, 28 Jul 1999 23:02:46 -0400 | From | Peter Desnoyers <> | Subject | clone, mm->count, and coredumps |
| |
I've been spending a lot of time debugging a threaded program lately, and have been bitten by the feature in the ELF coredump logic which disables corefile generation when current->mm->count != 1. (i.e. when any child processes have been created with CLONE_VM)
For the moment I've found a satisfactory (although ugly) workaround involving forking in a sigsegv handler and then faulting again.
However, I've been wondering at the logic behind this test. Is it assuming that mm->count is always 0 or 1, and so could be replaced with "->count == 0"? Is it because coredumps for threaded programs would otherwise be awfully lame, or is it just that my knowledge of using gdb on threaded corefiles is poor? (before I found this trick, I was able to generate corefiles on child threads, but they tended to always have the wrong stack as far as I could tell.) Is it some inscrutable reason related to devious virtual memory algorithms?
It strikes me that coredumps are as useful on threaded programs as on any other, and I wonder what would need to be done (in the kernel and in gdb) to get them working without application hackery.
Thoughts?
............................................................................ Peter Desnoyers 162 Pleasant St. (617) 661-1979 pjd@fred.cambridge.ma.us Cambridge, Mass. 02139 (978) 422-0402 (work) pjd@giga-net.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |