Upcoming changes to Thunderbird's tests

ISHIKAWA,chiaki ishikawa at yk.rim.or.jp
Thu Dec 26 10:09:20 UTC 2019

On 2019/12/25 20:15, Magnus Melin wrote:
> ./mach test 
> comm/mail/test/browser/composition/browser_imageInsertionDialog.js 


BTW, This is under Linux amd64.

I updated the source just in case this morning. I think several files 
were updated under ./comm subdirecotry as well as many under ./mozilla 
main directory.

Rebuilt TB.

Unfortunately, it is still NG, and I found the cause, I think.

The tail of the log shows: (there are a few locally added error logs.)

++ echo 'Your current directory is'
Your current directory is
++ pwd
++ /NREF-COMM-CENTRAL/mozilla/mach --log-no-times test 
environ.get('TERM', 'unknown')=xterm-256color
environ.get('TERM', 'linux')=xterm-256color
environ.get('TERM', 'unknown')=xterm-256color
environ.get('TERM', 'linux')=xterm-256color
  0:01.07 INFO Checking for ssltunnel processes...
  0:01.09 INFO Checking for xpcshell processes...
Error running mach:

     ['--log-no-times', 'test', 

The error occurred in code that was called by the mach command. This is 
a bug in the called code itself or in the way that mach is calling it.
You can invoke |./mach busted| to check if this issue is already on 
file. If it
isn't, please use |./mach busted file| to report it. If |./mach busted| is
misbehaving, you can also inspect the dependencies of bug 1543241.

If filing a bug, please include the full output of mach, including this 

The details of the failure are as follows:


   File "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/testing/mach_commands.py", 
line 387, in test
     argv=extra_args, test_objects=tests, **kwargs)
"/NEW-SSD/NREF-COMM-CENTRAL/mozilla/python/mach/mach/registrar.py", line 
152, in dispatch
     return self._run_command_handler(handler, context=context, **kwargs)
"/NEW-SSD/NREF-COMM-CENTRAL/mozilla/python/mach/mach/registrar.py", line 
109, in _run_command_handler
     result = fn(**kwargs)
line 447, in run_mochitest_general
line 142, in run_desktop_test
     result = mochitest.run_test_harness(parser, options)
line 3146, in run_test_harness
     result = runner.runTests(options)
line 2601, in runTests
     tests = self.getActiveTests(options)
line 1494, in getActiveTests
     assert pathAbs.startswith(self.testRootAbs)

real    0m4.087s
user    0m3.472s
sys    0m0.618s

Just to be sure,
I did clobber,
Still no go. :-(

Looks to me there is something wrong with the assert().

I inserted a couple of log.warnings statements in runtests.py just 
before the problematic assert().

             pathAbs = os.path.abspath(test['path'])
             self.log.warning('INFO: pathAbs=%s' % pathAbs)
             self.log.warning('INFO: self.testRootAbs=%s' % 
             assert pathAbs.startswith(self.testRootAbs)
             tp = pathAbs[len(self.testRootAbs):].replace('\\', 

Aha, I think there *ARE* problems.

 From the new log:

  0:00.49 WARNING INFO: 
  0:00.49 WARNING INFO: 
Error running mach:

Obviously, the pathAbs DOES NOT start with self.testRootAbs textually.

However, my /NREF-COMM-CENTRAL/mozilla main directory and an 
intermediate path to my MOZ_OBJ are actually symlinks to
the final directories.  And pathAbs DOES start with self.testRootAbs if 
symlinks are resolved.
(CORRECTION: To be exact, only the /KERNEL-SRC/moz-obj-dir part of the 
symlink is resolved.
We all know that the test files under MOZ_OBJ is actually symlinks to 
the ORIGINAL source files. So if we resolve THE final symlink in the 
path, we end up in the original source files and they DO NOT start with 
self.testRootAbs at all.)

Can this be a problem?

ishikawa at ip030:/NREF-COMM-CENTRAL/mozilla$ ls -l /NREF-COMM-CENTRAL
lrwxrwxrwx 1 root root 26 Oct 10 17:31 /NREF-COMM-CENTRAL -> 

from my mozconfig:
mk_add_options MOZ_OBJDIR=/KERNEL-SRC/moz-obj-dir/objdir-tb3

ishikawa at ip030:/NREF-COMM-CENTRAL/mozilla$ ls -l /KERNEL-SRC/moz-obj-dir
lrwxrwxrwx 1 root root 20 Oct  9 21:00 /KERNEL-SRC/moz-obj-dir -> 
ishikawa at ip030:/NREF-COMM-CENTRAL/mozilla$

Obnoxious thing is that |make mozmill| used to work without any issues 
with these symlink acrobatics at all.
(Symlink acrobatics were used to move TB source and object directories 
to new disks in the past without the need to update various shell 
scripts to test and analyze the log.)

I am tempted to remove the problematic assert for now and see how far I 
can go.

Should I file a bugzilla? I bet I should do. I will report whether 
removing the assert will get me far.

More information about the tb-planning mailing list