Bugzilla

Oh, I forgot to mention.

Thunderbird tries to inquire what graphics capabilites the host system has.
Under linux where I test my local build, it is done by probing done via X11 or known driver subsystems.
However, in the past, the graphics drivers had quirks and was prone to crashes when probled.
Thus TB (or for that matter, FF as well) FORKS itself to create a child process and does the
probe in the child process which may crash, but does not affect the main application.
The probe summary is sent back to the calling main application via pipe created during forking.

This is rather expensive operation under valgrind.

I noticed a rather lengthy pause during the invocation of TB.

After I figured out why TB under valgrind seems to get stuck without producing any output,
I changed TB code.
- In a normal run, TB would print out the probed summary sent back via the pipe, as hexadecimal
initializer for char array.
- Under valgrind, TB would not invoke fork and skip the real probe altogether, and instead the
data probed under normal processing (without valgrind) was made available in a character array and TB uses that for subsequent operation.

On a local machine, it was useful. One has to do this everytime a host changes hardware configuration.

Instead of forking and using pipes, if the mozilla code simply runs an external program that saves the probe data in a file under, say, /tmp
we can simply excludes the tracing of such an external program from valgrind easily.
But the code was not written that way today. So I took a short cut.

With the above mod, TB under valgrind during mochitest proceeds rather smoothly and I can focus on the real timeout issue (both in the test harness in itself, and the tests that seem to assume certain ordering of events without proper interlocking.).

Oh, I forgot to mention.

Thunderbird tries to inquire what graphics capabilites the host system has.
Under linux where I test my local build, it is done by probing done via X11 or known driver subsystems.
However, in the past, the graphics drivers had quirks and was prone to crashes when probed.
Thus TB (or for that matter, FF as well) FORKS itself to create a child process and does the
probe in the child process which may crash, but does not affect the main application.
The probe summary is sent back to the calling main application via pipe created during forking.

This is rather expensive operation under valgrind.

I noticed a rather lengthy pause during the invocation of TB under valgrind during mochitest.

After I figured out why TB under valgrind seems to get stuck without producing any output (that pause was during this external probe done by child process forked from the main application),
I changed TB code.
- In a normal run, TB would print out the probed summary sent back via the pipe, as hexadecimal
initializer for char array.
- Under valgrind, TB would not invoke fork and skip the real probe altogether, and instead the
data probed under normal processing (without valgrind) was made available in a character array and TB uses that for subsequent operation.

On a local test machine, it has turned out rather useful. One has to do this every time a host changes hardware configuration.

With the above mod, TB under valgrind during mochitest proceeds rather smoothly and I can focus on the real timeout issue (both in the test harness in itself, and the tests that seem to assume certain ordering of events without proper interlocking.).

Instead of forking and using pipes, if the mozilla code simply runs an external program that saves the probe data in a file under, say, /tmp
we can simply excludes the tracing of such an external program from valgrind easily to save CPU workloa.
However,  the code was not written that way today. So I took a short cut.

Oh, I forgot to mention.

Thunderbird tries to inquire what graphics capabilites the host system has.
Under linux where I test my local build, it is done by probing done via X11 or known driver subsystems.
However, in the past, the graphics drivers had quirks and was prone to crashes when probed.
Thus TB (or for that matter, FF as well) FORKS itself to create a child process and does the
probe in the child process which may crash, but does not affect the main application.
The probe summary is sent back to the calling main application via pipe created during forking.

This is rather expensive operation under valgrind.

I noticed a rather lengthy pause during the invocation of TB under valgrind during mochitest.

After I figured out why TB under valgrind seems to get stuck without producing any output (that pause was during this external probe done by child process forked from the main application),
I changed TB code.
- In a normal run, TB would print out the probed summary sent back via the pipe, as hexadecimal
initializer for char array.
- Under valgrind, TB would not invoke fork and skip the real probe altogether, and instead the
data probed under normal processing (without valgrind) was made available in a character array and TB uses that for subsequent operation.

On a local test machine, it has turned out rather useful. One has to do this every time a host changes hardware configuration.

With the above mod, TB under valgrind during mochitest proceeds rather smoothly and I can focus on the real timeout issue (both in the test harness in itself, and the tests that seem to assume certain ordering of events without proper interlocking or waiting enough under valgrind.).

Instead of forking and using pipes, if the mozilla code simply runs an external program that saves the probe data in a file under, say, /tmp
we can simply excludes the tracing of such an external program from valgrind easily to save CPU workloa.
However,  the code was not written that way today. So I took a short cut.

Oh, I forgot to mention.

Thunderbird tries to inquire what graphics capabilites the host system has.
Under linux where I test my local build, it is done by probing done via X11 or known driver subsystems.
However, in the past, the graphics drivers had quirks and was prone to crashes when probed.
Thus TB (or for that matter, FF as well) FORKS itself to create a child process and does the
probe in the child process which may crash, but does not affect the main application.
The probe summary is sent back to the calling main application via pipe created during forking.

This is rather expensive operation under valgrind.

I noticed a rather lengthy pause during the invocation of TB under valgrind during mochitest.

After I figured out why TB under valgrind seems to get stuck without producing any output (that pause was during this external probe done by child process forked from the main application),
I changed TB code.
- In a normal run, TB would print out the probed summary sent back via the pipe, as hexadecimal
initializer for char array.
- Under valgrind, TB would not invoke fork and skip the real probe altogether, and instead the
data probed under normal processing (without valgrind) was made available in a character array and TB uses that for subsequent operation.

On a local test machine, it has turned out rather useful. One has to do this every time a host changes hardware configuration.

With the above mod, TB under valgrind during mochitest proceeds rather smoothly and I can focus on the real timeout issue (both in the test harness in itself, and the tests that seem to assume certain ordering of events without proper interlocking or waiting enough under valgrind.).

Instead of forking and using pipes, if the mozilla code simply runs an external program that saves the probe data in a file under, say, /tmp
we can simply excludes the tracing of such an external program from valgrind easily to save CPU workload.
However,  the code was not written that way today. So I took a short cut.