543241 - FreeBSD NS_IsMainThread() isn't working (TLS broken?)

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Marco Perez [:mpk]]

Current Fennec trunk builds crash at startup. This behaviour is reproducible
with at least FreeBSD 7 and 8 (i386 & amd64). The same happens with Firefox
when it is build using "--with-libxul-sdk=..." in mozconfig.

Rev 032a9a176ee7 runs okay whereas rev 24ce78dd533f already exhibits the bug.
So I suspect bug 521750 to be the cause of this regression.

The debug output of "./fennec -safe-mode" spits out the following:
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 667
(note: this message repeats itself another 25 times)
[ ... ]
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 580
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 587
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 587
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 667
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 580
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 587
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 587
###!!! ASSERTION: Startup not on main thread?: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/components/nsNativeComponentLoader.cpp,
       line 103
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 667
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 580
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 587
###!!! ASSERTION: wrong thread: 'NS_IsMainThread()',
       file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 587
*** Registering components in: (note: it registers a total of 51 components)
[ ... ]
Illegal instruction (core dumped)

Comment 1

[timeless]

please build firefox --disable-optimize --enable-debugger-info-modules, set 
XPCOM_DEBUG_BREAK=break
and run ./firefox -g -d gdb

we only need the first stack trace to the assertion....

Comment 2

[Marco Perez [:mpk]]

OK, here we go:

(gdb) bt
#0  RealBreak ()
    at /work/src/mozilla/xpcom/base/nsDebugImpl.cpp:421
#1  0x00000008037e1d31 in Break (aMsg=0x7fffffffbc50 "###!!!
    ASSERTION: wrong thread: 'NS_IsMainThread()',
    file /work/src/mozilla/xpcom/ds/nsAtomTable.cpp, line 667")
    at /work/src/mozilla/xpcom/base/nsDebugImpl.cpp:517
#2  0x00000008037e2485 in NS_DebugBreak_P
     (aSeverity=1,
      aStr=0x803d3b3f8 "wrong thread",
      aExpr=0x803d3b3e6 "NS_IsMainThread()",
      aFile=0x803d3b058 "/work/src/mozilla/xpcom/ds/nsAtomTable.cpp",
      aLine=667)
    at /work/src/mozilla/xpcom/base/nsDebugImpl.cpp:360
#3  0x00000008037746b0 in GetAtomHashEntry
     (aString=0x803d404e5 "XCurProcD",
      aLength=9)
    at /work/src/mozilla/xpcom/ds/nsAtomTable.cpp:667
#4  0x000000080377589e in NS_RegisterStaticAtoms
     (aAtoms=0x804040ec0,
      aAtomCount=24)
    at /work/src/mozilla/xpcom/ds/nsAtomTable.cpp:720
#5  0x000000080379a847 in nsDirectoryService::RealInit ()
    at /work/src/mozilla/xpcom/io/nsDirectoryService.cpp:513
#6  0x000000080376f9a3 in NS_InitXPCOM3_P
     (result=0x7fffffffc410,
      binDirectory=0x800e2a800,
      appFileLocationProvider=0x7fffffffcac0,
      staticComponents=0x803e76100,
      componentCount=51)
    at /work/src/mozilla/xpcom/build/nsXPComInit.cpp:551
#7  0x00000008024d03ca in ScopedXPCOMStartup::Initialize
     (this=0x7fffffffc410)
    at /work/src/mozilla/toolkit/xre/nsAppRunner.cpp:1099
#8  0x00000008024d056e in ImportProfiles
     (aPService=0x800eba150,
      aNative=0x800e68da0)
    at /work/src/mozilla/toolkit/xre/nsAppRunner.cpp:1946
#9  0x00000008024d22f7 in SelectProfile
     (aResult=0x7fffffffccd0,
      aNative=0x800e68da0,
      aStartOffline=0x7fffffffcccc,
      aProfileName=0x7fffffffca00)
    at /work/src/mozilla/toolkit/xre/nsAppRunner.cpp:2119
#10 0x00000008024d45ab in XRE_main
     (argc=2,
      argv=0x7fffffffea88,
      aAppData=0x800e40080)
    at /work/src/mozilla/toolkit/xre/nsAppRunner.cpp:3164
#11 0x0000000000401f40 in main
     (argc=2,
      argv=0x7fffffffea88)
    at /work/src/mozilla/xulrunner/stub/nsXULStub.cpp:583

Comment 3

[Marco Perez [:mpk]]

Attachment: full stacktrace (using Firefox on top of XULRunner)

And here's the full stacktrace in case my last comment doesn't provide enough
information.

Comment 4

[timeless]

so, something's wrong, that looks like the main thread....

can you try updating to 611a06f94bb6 and building? if that works, try updating to 24ce78dd533f, my guess is that it'll break there, in which case the problem is TLS.

Comment 5

[Marco Perez [:mpk]]

Isn't 611a06f94bb6 a bit old? There's been quite a lot of activity since then:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=611a06f94bb6&tochange=24ce78dd533f

24ce78dd533f is indeed already broken, whereas 032a9a176ee7 still ran fine
(see the original report):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=032a9a176ee7&tochange=24ce78dd533f

I'll try building 611a06f94bb6 anyway.

Comment 6

[Marco Perez [:mpk]]

Unfortunately I had no luck building either Firefox or Fennec atop XULRunner
using rev 611a06f94bb6. I had to resort to TestGtkEmbed. It seemed to suffer
from the same bug lately, but the one built with rev 611a06f94bb6 ran okay
(at least on FreeBSD 7 (i386)).

If there's something else I could build or test that would be helpful,just
let me know.

Comment 7

[Jan Beich]

Can you confirm that it works fine after
http://svn.freebsd.org/changeset/base/225582
http://svn.freebsd.org/changeset/base/226155
http://svn.freebsd.org/changeset/base/226156
?

There is also a workaround for old releases without r225582 in ports
http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/firefox/files/patch-xpcom__threads__nsThreadManager.cpp

Comment 8

[Marco Perez [:mpk]]

I'm not sure when these were MFCed, but I can confirm that current trunk builds
on a fairly recent (2012-07-01) FreeBSD 9-stable system build and run without
any major problems. Especially the crash I mentioned earlier seems gone now.
I've tried both Firefox (browser) and Fennec (mobile).

Marking WORKSFORME since it was fixed (and obviously MFCed) upstream.