Bug: C-C TB mochitest does not run locally on a linux PC due to an assertion.:  GECKO(119773) Assertion failure: !mRawPtr, at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/StaticPtr.h:51
Status: NEW
Priority: --
Created: 2020-01-10 19:25:53+00:00
Resolved: 2022-10-11 23:49:53+00:00

Debian GNU/Linux amd64. 
Imake mozmill| used to work until December on the same PC, so it is hard to believe that there is a binary toolchain issue, but I cannot rule it out.

The main part of the  error log (longer one is attached) is:

```

 0:02.12 GECKO(119773) [119773, Unnamed thread 556442d30950] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/xpcom/base/nsTraceRefcnt.cpp, line 198
 0:02.12 GECKO(119773) ### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /COMM-CENTRAL/TMP-DIR/tmpIWM7ka.mozrunner/runtests_leaks.log
 0:02.12 GECKO(119773) Assertion failure: !mRawPtr, at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/StaticPtr.h:51
 0:02.45 GECKO(119773) #01: __static_initialization_and_destruction_0(int, int) (/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:42)
 0:02.46 GECKO(119773) #02: _GLOBAL__sub_I_Unified_cpp_xpcom_base2.cpp (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/xpcom/base/nsWeakReference.cpp:160)
 0:02.53 GECKO(119773) #03: call_init (/build/glibc-suXNNi/glibc-2.29/elf/dl-init.c:71)
 0:02.53 GECKO(119773) #04: _dl_init (/build/glibc-suXNNi/glibc-2.29/elf/dl-init.c:118)
 0:02.53 GECKO(119773) #05: dl_open_worker (/build/glibc-suXNNi/glibc-2.29/elf/dl-open.c:520)
 0:02.67 GECKO(119773) #06: __GI__dl_catch_exception (/build/glibc-suXNNi/glibc-2.29/elf/dl-error-skeleton.c:197)
 0:02.67 GECKO(119773) #07: _dl_open (/build/glibc-suXNNi/glibc-2.29/elf/dl-open.c:599)
 0:02.73 GECKO(119773) #08: dlopen_doit (/build/glibc-suXNNi/glibc-2.29/dlfcn/dlopen.c:66 (discriminator 8))
 0:02.73 GECKO(119773) #09: __GI__dl_catch_exception (/build/glibc-suXNNi/glibc-2.29/elf/dl-error-skeleton.c:197)
 0:02.74 GECKO(119773) #10: __GI__dl_catch_error (/build/glibc-suXNNi/glibc-2.29/elf/dl-error-skeleton.c:216)
 0:02.74 GECKO(119773) #11: _dlerror_run (/build/glibc-suXNNi/glibc-2.29/dlfcn/dlerror.c:174)
 0:02.74 GECKO(119773) #12: __dlopen (/build/glibc-suXNNi/glibc-2.29/dlfcn/dlopen.c:87)
 0:02.82 GECKO(119773) #13: GetLibHandle(char const*) (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/xpcom/glue/standalone/nsXPCOMGlue.cpp:85)
 0:02.82 GECKO(119773) #14: ReadDependentCB(char const*, mozilla::LibLoadingStrategy) (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/xpcom/glue/standalone/nsXPCOMGlue.cpp:135)
 0:02.82 GECKO(119773) #15: XPCOMGlueLoad(char const*, mozilla::LibLoadingStrategy) (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/xpcom/glue/standalone/nsXPCOMGlue.cpp:309)
 0:02.82 GECKO(119773) #16: mozilla::GetBootstrap(char const*, mozilla::LibLoadingStrategy) (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/xpcom/glue/standalone/nsXPCOMGlue.cpp:377)
 0:02.82 GECKO(119773) #17: InitXPCOMGlue() (/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/UniquePtr.h:314)
 0:02.82 GECKO(119773) #18: main (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mail/app/nsMailApp.cpp:314 (discriminator 4))
 0:02.82 GECKO(119773) #19: __libc_start_main (/build/glibc-suXNNi/glibc-2.29/csu/../csu/libc-start.c:342)
 0:02.82 GECKO(119773) #20: _start (/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/thunderbird)
 0:02.82 GECKO(119773) #21: ??? (???:???)
 2:02.12 INFO runtests.py | Waiting for browser...
```
As I say, |make mozmill| used to work on this PC.
xpcshell test works, too (with the usual assortment of strange errors:maybe timing dependent, etc.)

So it is hard to believe there is a binary toolchain issue, but who knows...
My compilation command looks like the following (from the last compilation)
```
/usr/bin/ccache /usr/bin/g++-9 -std=gnu++17 -o nsParseMailbox.o -c  -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/stl_wrappers -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/system_wrappers -include /NEW-SSD/NREF-COMM-CENTRAL/mozilla/config/gcc_hidden.h -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -DDEBUG=1 -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/local/src -I/NEW-SSD/moz-obj-dir/objdir-tb3/comm/mailnews/local/src -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nspr -I/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/nss -fPIC -DMOZILLA_CLIENT -include /NEW-SSD/moz-obj-dir/objdir-tb3/mozilla-config.h -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-error=multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat -Wformat-overflow=2 -fno-sized-deallocation -fno-aligned-new -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -DUSEVALGRIND=1 -DDEBUG -g -gsplit-dwarf -Werror=sign-compare -Werror=unused-result -Werror=unused-variable -Werror=format -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -g -Og -fvar-tracking -gdwarf-4 -fvar-tracking-assignments -freorder-blocks -fno-omit-frame-pointer -funwind-tables  -MD -MP -MF .deps/nsParseMailbox.o.pp  -fdiagnostics-color  /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/local/src/nsParseMailbox.cpp

```
I use gnu c++ version 9. Again, since xpcshell test works, and thunderbird binary seems to run without serious issue. (At least, I get past the OS integration dialog after a new compilation and start TB afresh.) So I don't believe TB binary itself is to blame.
Maybe some binary components that is used for mochitest (GEKCO?).
I use GNU gold as the local linker.

Being able to test TB locally is very important or I will simply submit frivolous changes to the mozilla test farm which would be a waste of resources (IMHO or maybe that is the idea of the compilation farm since the beginning?). 

Any tips to dive into the root cause of the issue will be appreciated.