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/