917757 - GenerationalGC: Browser build error in make package

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jon Coppeard (:jonco)]

Working yesterday, but now I get the following doing a browser build with generational GC enabled:

WARNING: NS_ENSURE_TRUE(thread) failed: file ../../../xpcom/glue/nsThreadUtils.cpp, line 174
WARNING: NS_ENSURE_TRUE(thread) failed: file ../../../xpcom/glue/nsThreadUtils.cpp, line 174
WARNING: NS_ENSURE_TRUE(thread) failed: file ../../../xpcom/glue/nsThreadUtils.cpp, line 174
WARNING: NS_ENSURE_TRUE(mMainThread) failed: file ../../../xpcom/threads/nsThreadManager.cpp, line 249
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0xC1F30001: file ../../../xpcom/glue/nsThreadUtils.cpp, line 161
Traceback (most recent call last):
  File "/builds/slave/try-osx64-d-000000000000000000/build/toolkit/mozapps/installer/packager.py", line 375, in <module>
    main()
  File "/builds/slave/try-osx64-d-000000000000000000/build/toolkit/mozapps/installer/packager.py", line 367, in main
    args.source, gre_path, base)
  File "/builds/slave/try-osx64-d-000000000000000000/build/toolkit/mozapps/installer/packager.py", line 148, in precompile_cache
    errors.fatal('Error while running startup cache precompilation')
  File "/builds/slave/try-osx64-d-000000000000000000/build/python/mozbuild/mozpack/errors.py", line 101, in fatal
    self._handle(self.FATAL, msg)
  File "/builds/slave/try-osx64-d-000000000000000000/build/python/mozbuild/mozpack/errors.py", line 96, in _handle
    raise ErrorMessage(msg)
mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation
make[3]: *** [stage-package] Error 1
make[2]: *** [make-package] Error 2
make[1]: *** [default] Error 2
make: *** [package] Error 2

Comment 1

[Jon Coppeard (:jonco)]

Bisection shows that this was triggered by the fix for bug 905926.  I've had a look at the changes and it's fairly involved, but nothing really jumps out.

bholley, any ideas?

Comment 2

[Bobby Holley (:bholley)]

|mach build stage-package| invokes precompile_cache, which is a script that runs in xpcshell and does all kinds of crazy stuff (it's bitten me before). This test alters a lot of shutdown GC behavior in a way that affects xpcshell, so I'm not too surprised.

The patches in bug 905926 are themselves bisecatable, so you can bisect into them and get an even better idea of what specifically caused the issue.

Comment 3

[Jon Coppeard (:jonco)]

(In reply to Bobby Holley (:bholley) from comment #2)

Looks like it's this one:

Stop creating an ephemeral JSContext during XPConnect shutdown
https://hg.mozilla.org/mozilla-central/rev/338b7a7e8561

Comment 4

[Bobby Holley (:bholley)]

Oh hm, maybe the patch ordering isn't totally right (that is to say, a bisection here may not be meaningful). The patch to stop using hasContexts() comes _after_ this one, which means that this patch introduces an ephemeral behavior change.

Anyway, can you manually invoke precompile_cache with all the patches applied and see why it's failing?

Comment 5

[Jon Coppeard (:jonco)]

Attachment: xpcshell-shutdown-crash

Ok, it looks like post barriers triggered in shutdown are accessing memory that's already been freed.

I don't understand how the XPConnect shutdown sequence works, but it seems we should stop postbarriers happening at this point.  I couldn't think of a better way of doing this than using unsafeGet().

I've verified that this fixes the 'make package' issue and pushed a try build.

Comment 6

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/289fcfb608d6

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/289fcfb608d6