I can't speak for what TB development plan is.
One thing I observe as an occasional submitter of TB patches is this.
Thunderbird ditched |mozmill| test December 2019, and switched to
mochitest in place of mozmill test.
Unfortunately, valgrind no longer works locally for mochitest.
This is quite a loss for keeping the code in sane state. I have
uncovered quite a few memory-related bugs over the years by running TB
under valgrind during mozmill-based test.
(I don't know if there is any official valgrind run of TB on tryserver
despite arcane description I read years ago that
it was performed from time to time.).
xpcshell-tests still runs under valgrind. I found a few memory-related
errors by running TB under valgrind during xpcshell-tests this year.
So for me, valgrind test is very important for keeping TB in sane state
after a large patch set lands, etc.
(Actually, I have a large patch set that enables buffered-write for
message handling and this will boost write performance very much. But it
is a rather lage patch set, and I want to run tests under valgrind to
make sure nothing undesirable is introduced.)
Looking at the posts, I have a feeling that TB may be able to run under
valgrind during mochitest if this
e10s setting is properly handled. Right now, TB under valgrind during
mochitest starts more than 1500 threads (too many IMHO), but less than
5000 threads (I have not figured out exactly how many threads are
required), and valgrind barfs. I need to increase the number of threads
valgrind supports,
but maybe because of the large number of threads, tests time out before
anything useful is performed. Thus no useful memory test is done under
mochitest currently.
Something is wrong there.
I suspect this e10s setting *may* have a bit to do with the situation.
I think I have to make sure TB runs in non e10s mode to run under
valgrind during mochitest.
Specifically I am not sure if the setting is honored in test user
profile prepared for mochitest.:
https://searchfox.org/comm-central/rev/e62a0af3cba6e1c65b2d4be02d3fefce88cf3f8f/mail/app/profile/all-thunderbird.js#654
||
|// No e10s in Thunderbird for now. |
|pref("browser.tabs.remote.autostart", false); |
||
*Maybe*, by making sure that this is set to false, valgrind might work
under mochitest.
Maybe a fishing trip in the coming weekend.
Chiaki
On 2020/06/11 4:05, Gijs Kruitbosch wrote:
I can't speak for Thunderbird's plans, but either way these plans
shouldn't affect them and is restricted to desktop Firefox; the pref
still works there:
https://searchfox.org/mozilla-central/rev/4bb2401ecbfce89af06fb2b4d0ea3557682bd8ff/toolkit/xre/nsAppRunner.cpp#5020-5024
, and they set it:
https://searchfox.org/comm-central/rev/e62a0af3cba6e1c65b2d4be02d3fefce88cf3f8f/mail/app/profile/all-thunderbird.js#654
Of course, if TB needs this configuration then that may complicate
removing support for non-e10s entirely...
~ Gijs
On 10/06/2020 19:56, Emilio Cobos Álvarez wrote:
What is the situation of Thunderbird? I think they don't have e10s
enabled
yet, and it may be worth at least knowing what their plans are.
-- Emilio
On Wed, Jun 10, 2020, 8:44 PM Dave Townsend <dtowns...@mozilla.com>
wrote:
Non-e10s is such a different environment that I don't think we have any
hope of keeping it working without running the full test suite in
that mode
and I don't think anyone wants to do that. Now that this has started
breaking I think it is actively harmful to our users for us to allow
them
to disable e10s.
On Wed, Jun 10, 2020 at 11:30 AM Gijs Kruitbosch
<gijskruitbo...@gmail.com
wrote:
(Copied to fx-dev; Replies to dev-platform please.)
Hello,
Just over a year ago, I started a discussion[0] about our support for
disabling e10s. The outcome of that was that we removed support for
disabling e10s with a pref on Desktop Firefox with version 68, except
for use from automation. We kept support for using the environment
variable. [1]
Last week, we released Firefox 77, which turned out to break all
webpages sent using compression (like gzip) if you had disabled e10s
using this environment variable. [2]
So here we are again. I'd like to propose we also stop honouring the
environment variable unless we're running tests in automation. We
clearly do not have sufficient test coverage to guarantee basic things
like "the browser works", it lacks security sandboxing, and a
number of
other projects require it (fission, gpu process, socket process, ...),
so I think it's time to stop supporting this configuration at all.
I hope to make this change for the 79 cycle. I'm open to arguments
either way about what to do for 78 esr (assuming the patch for 79
turns
out to be simple; the work to remove the pref had a number of annoying
corner-cases at the time).
Please speak up if you think that this plan needs adjusting.
~ Gijs
[0]
https://groups.google.com/d/msg/mozilla.dev.platform/cJMzxi7_PmI/Pi1IOg_wCQAJ
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548941
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1638652
_______________________________________________
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
