Bug: Strange errors TB displays when it is executed under valgrind.
Status: NEW
Priority: --
Created: 2021-09-28 07:08:09+00:00
Resolved: 2025-01-20 09:12:41+00:00

I have been trying to run TB under valgrind during mochitest test suite.
So far, no success.
See bug 1629433, bug 1636945, for example.

Right now, I　cannot execute TB under valgrind successfully even for simple start and then download a message and exit. (I cannot download a message. There is an error.)

While I try to investigate why the download cannot be done under valgrind, I hereby report this and a few other errors which I don't see in the normal TB operation of (start, exit.)
I also throw in the difference I found between the successful TB mochitest run (a single javascript test target) and the one that fails due to timeout under valgrind.

- 1. I see the following errors near the beginning of execution when TB is run under valgrind. Simple startup and exit.

```
//
Couldn't convert chrome URL: chrome://branding/locale/brand.properties
[Child 945917, Main Thread] WARNING: Could not get the program name for a cubeb stream.: 'NS_SUCCEEDED(rv)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/media/CubebUtils.cpp:383
Warning: asking to enable_gpu_markers but no supporting extension was found
//
```

This error  comes from the following code and is related to some media thread processing?
  https://searchfox.org/mozilla-central/source/dom/media/CubebUtils.cpp#385

It is really strange that this error is reported ONLY for TB under valgrind and normal TB does not report this error during startup.
The errors are observed by TB under valgrind during mochitest, too.

- 2.  During mochitest, TB under valgrind shows the following errors. Normal TB doesn't show them. I　wonder why.
I suppose some timing difference causes this, but how?

The error comes from the source:
https://searchfox.org/mozilla-central/source/dom/media/gmp/GMPServiceParent.cpp#770
```
 4:16.67 GECKO(922612) [Parent 922612, GMPThread] WARNING: Denying media plugin load due to lack of sandboxing.: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/media/gmp/GMPServiceParent.cpp:770
 4:16.67 GECKO(922612) [Parent 922612, GMPThread] WARNING: Can't Create GMPParent: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/media/gmp/GMPServiceParent.cpp:826
 4:16.72 GECKO(922612) [Parent 922612, GMPThread] WARNING: Denying media plugin load due to lack of sandboxing.: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/media/gmp/GMPServiceParent.cpp:770
 4:16.73 GECKO(922612) [Parent 922612, GMPThread] WARNING: Can't Create GMPParent: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/media/gmp/GMPServiceParent.cpp:826
 4:16.73 GECKO(922612) [Parent 922612, GMPThread] WARNING: Denying media plugin load due to lack of sandboxing.: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/media/gmp/GMPServiceParent.cpp:770
 4:16.75 GECKO(922612) [Parent 922612, GMPThread] WARNING: Can't Create GMPParent: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/media/gmp/GMPServiceParent.cpp:826
 4:16.77 GECKO(922612) [Parent 922612, GMPThread] WARNING: Failed to delete GMP storage directory: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/media/gmp/GMPServiceParent.cpp:1623
```
Again,  I wonder if these errors are responsible for the eventual timing out of TB under valgrind without finishing mochitest successfully. 

The above errors are not printed by TB under valgrind (start, exit).

- 3.  During start, download, exit sequence, TB under valgrind fails to download a message.
This is natural because it FAILS to prompt for the server password. Normal TB prompts the password. 
So there is something wrong with TB. Slow execution time under valgrind must skew some implicit timing assumptions and the password prompt does not appear at all (!).

```
JavaScript error: chrome://messenger/content/mailWindowOverlay.js, line 3012: : Component returned failure code: 0x8055000a [nsIMsgIncomingServer.getNewMessages]
JavaScript error: chrome://messenger/content/mailWindowOverlay.js, line 3012: : Component returned failure code: 0x8055000a [nsIMsgIncomingServer.getNewMessages]
[Parent 945649, Main Thread] WARNING: 'NS_FAILED(rv)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/xpcom/io/SlicedInputStream.cpp:172

```

- 4. There is also a memory access to already free'ed area in TB under valgrind. (Maybe the skwed timing causes sync miss, thus causing a should-not-happen situation.
Address 0xC3C3C3...C3 is a value overwritten by valgrind when a memory area is freed.
( --free-fill=0xC3 )

```
==945649== Invalid read of size 8
==945649==    at 0xCAFA2C6: mozilla::detail::RunnableFunction<nsXULPopupManager::ShowMenu(nsIContent*, bool, bool)::{lambda()#1}>::Run() (nsCOMPtr.h:529)
==945649==    by 0x9373615: mozilla::RunnableTask::Run() (TaskController.cpp:467)
==945649==    by 0x9372428: mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (TaskController.cpp:770)
==945649==    by 0x9372BAA: mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (TaskController.cpp:606)
==945649==    by 0x9372EBB: mozilla::TaskController::ProcessPendingMTTask(bool) (TaskController.cpp:390)
==945649==    by 0x9372F8A: mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::{lambda()#1}>::Run() (TaskController.cpp:123)
==945649==    by 0x9373BD1: nsThread::ProcessNextEvent(bool, bool*) (nsThread.cpp:1148)
==945649==    by 0x9353CD9: NS_ProcessNextEvent(nsIThread*, bool) (nsThreadUtils.cpp:466)
==945649==    by 0x9A798B9: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (MessagePump.cpp:85)
==945649==    by 0x9A1C3D8: MessageLoop::Run() (message_loop.cc:324)
==945649==    by 0xC4C8BB8: nsBaseAppShell::Run() (nsBaseAppShell.cpp:137)
==945649==    by 0xDA25C81: nsAppStartup::Run() (nsAppStartup.cpp:289)
==945649==    by 0xDB25935: XREMain::XRE_mainRun() (nsAppRunner.cpp:5291)
==945649==    by 0xDB26DCC: XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (nsAppRunner.cpp:5476)
==945649==    by 0xDB276E8: XRE_main(int, char**, mozilla::BootstrapConfig const&) (nsAppRunner.cpp:5535)
==945649==    by 0x11E833: do_main(int, char**, char**) (nsMailApp.cpp:229)
==945649==    by 0x11DAA2: main (nsMailApp.cpp:368)
==945649==  Address 0xc3c3c3c3c3c3c3c3 is not stack'd, malloc'd or (recently) free'd
==945649==
{
```
There seem to be a  genuine problem, and a few sync issues that cause logical errors in TB aside from the somewhat short timeout values in test harness. The thing is, the above address error (0xC3C3C3...C3) does not happen always. That means there is a race.

I am still investigating.