Bug: Running thunderbird binary under valgrind while trying to run mochitest requires way TOO MANY threads (> 1500) !?
Status: NEW
Priority: --
Created: 2020-04-12 22:26:42+00:00
Resolved: 2025-01-20 10:57:46+00:00

Note: "thread" here refers to the mult-threading on CPU. Not the threading of topics of mail messages.

--

I have tried to run thunderbird binary under valgrind while executing |mach mochitest|.

valgrind blows up stating that there are simply too many threads being created.
I upped the maximum number of threads supported by valgrind via its --max-threads=NNN parameter. I upped it to 1500 and valgrind still blew up.

So there is something very wrong with valgrind+thunderbird binary combination when |mach mochitest| is executed.

Background: 

I am not sure how valgrind run is supported for mochitest of TB, and so
I created a binary that executes, under valgrind, the original thunderbird binary (created as thunderbird-bin)under MOZ_OBJ/dist/bin directory. 
The new binary to invoke thunderbird-bin under valgrind is copied into MOZ_OBJ/dist/bin/thunderbird.

This arrangement has worked fine with xpcshell-tests and |make
mozmill| test suite for some years.

I tested the xcpshell-tests under valgrind in this manner as late as the end of Feb 22 of this year. It worked fine.

Ever since |make mozmill| was retired in December 2019,  I have tried to run |mach mochitest| running thunderbird under valgrind to check memory-related issues of TB.
Unfortunately, I have not been successful so far with this too many threads issue.

Regarding |mach mochitest|:

Without valgrind, the use of "no target", i.e., specifying no target after |mochitest| command seems to run the all the subtests of mochitest suite intended for TB after I |cd|ed to the C-C  ./comm subdirectory of M-C ./mozilla directory.

However, with the same target, if I run TB under valgrind, the valgrind run blows up saying
too many tasks (default 500 and even if I increased it to 1500) and this happened even before a SINGLE test is run.

So I suspect one of the following causes.:

1. The default mochitest setup consumes THAT MANY tasks (Does anyone if this is also the case with valgrind test of FF run that is done a few weeks apart or every month? In that case, adding

"--max-threads=NNN "  /* April, 2020. */

to valgrind argument seems to be the way to go. But still, even NNN=1500 did not solve the issue at all (!)

2. TB's mochitest invoked inside valgrind does something funny to create so many tasks, or.

3. Possible valgrind issue:

I notice that valgrind printed the following warning during local run, which is a known valgrind issue.: 

  0:21.22 GECKO(275735) --275739-- WARNING: unhandled amd64-linux syscall: 315

https://github.com/svn2github/valgrind-master-mirror/blob/master/docs/internals/3_12_BUGSTATUS.txt

(My valgrind is farily recent.: valgrind --version
valgrind-3.16.0.GIT )

syscall 315 is |sched_getattr|. So it *IS* possible that there could be some issues related to task scheduling and creation.
But if so, there can and should be a problem with FF run under valgrind as well. But I could not find it in bugzilla. I am a bit puzzled.

I am uploading an excerpt from my local log in the next comment.