Though the context ( registers etc ) at the time of dump for the thread
dumping core match the ones at theattime of dump , the data in the dump
will not reflect the MM data at that point in time for the above reason.
thanks,
Rama.
> 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/
>
-
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/