|
From: ISHIKAWA,chiaki <ish...@yk...> - 2013-04-10 00:41:57
|
My comment inline:
(2013/04/10 4:01), John Reiser wrote:
>> I got the following output from valgrind/memcheck while
>> I was testing mozilla thunderbird using its test framework, "make mozmill".
>
>> 1. Can this unfamiliar clone be supported?
>
>> ==803== Unsupported clone() flags: 0x800600
>
> Perhaps. Here is an analysis plus something that you can attempt:
>
> ----- /usr/include/bits/sched.h:
> # define CLONE_VM 0x00000100 /* Set if VM shared between processes. */
>
> # define CLONE_FS 0x00000200 /* Set if fs info shared between processes. */
> # define CLONE_FILES 0x00000400 /* Set if open files shared between processes. */
>
> # define CLONE_VFORK 0x00004000 /* Set if the parent wants the child to
> wake it up on mm_release. */
>
> # define CLONE_UNTRACED 0x00800000 /* Set if the tracing process can't
> force CLONE_PTRACE on this clone. */
>
> ----- coregrind/m_syswrap/syswrap-amd64-linux.c
I take that 32-bit version behaves the same.
(I am using 32-bit Debian GNU/Linux.)
> /* Only look at the flags we really care about */
> switch (cloneflags & (VKI_CLONE_VM | VKI_CLONE_FS
> | VKI_CLONE_FILES | VKI_CLONE_VFORK)) {
> case VKI_CLONE_VM | VKI_CLONE_FS | VKI_CLONE_FILES:
> /* thread creation */
> <<snip>>
>
> case VKI_CLONE_VFORK | VKI_CLONE_VM: /* vfork */
> /* FALLTHROUGH - assume vfork == fork */
> cloneflags &= ~(VKI_CLONE_VFORK | VKI_CLONE_VM);
>
> case 0: /* plain fork */
> <<snip>>
>
> default:
> /* should we just ENOSYS? */
> VG_(message)(Vg_UserMsg,
> "Unsupported clone() flags: 0x%lx\n", ARG1);
> -----
>
> So by omitting VKI_CLONE_VM from flags then mozilla is *not* making a new thread,
> but instead is making a new process via "plain fork". However, a plain fork
> with CLONE_FS and CLONE_FILES set (that is, a separate process that *shares*
> filesystem info and open files with its parent) is not something that coregrind
> understands. I'm not sure I understand it, either. What do the mozilla comments
> say? What is mozilla trying to accomplish by clone() with those peculiar flags?
I have no idea, but I think mozilla thunderbird was trying to invoke its crash
reporter after detecting memory error on its own using a signal handler via SIGSEGV or something.
>
> After that, then the first thing to try is to tail-merge mozilla's special case
> into coregrind's "plain fork":
>
> case VKI_CLONE_FS | VKI_CLONE_FILES: /* DEBUG: mozilla special case */
> /* FALLTHROUGH into plain fork */
>
> case 0: /* plain fork */
>
> Re-build valgrind (including "make install") and try that.
>
Thank you for the suggestion. I will try this.
*BUT*, this memory error may or may not happen during "make mozmill" always.
It seems that it can be caused by memory corruption due to races and thus
highly timing dependent.
I encountered the error for the first time during testing mozilla thunderbird
since last November when I began tinkering with thunderbird and valgrind.
So I am not holding a breath, but when my run encounters another manifestation of the bug
and valgrind proceeds further with the above change, I will report it.
BTW, do you have any idea about "adding the dump of thread info about
all the threads (maybe enabled on/off by a command switch)
when valgrind/memcheck detects serious memory error "?
After fixing the strange repetition of same addresses (numerical address),
which seems to be a bug, or we can simply omit the repetition of the same numbers after a few times,
the dump will be very useful.
I learned about the status of the threads in thunderbird
for the first time after seeing the dump myself :-)
(I am not the author of TB, and am just trying to figure out where some crashes I experienced
in real life could have been caused, so that people in the know could home
in the buggy places to fix them.)
Thank you, valgrind community, for sharing this wonderful tool!
|