Closed Bug 917757 Opened 10 years ago Closed 10 years ago

GenerationalGC: Browser build error in make package


(Core :: JavaScript Engine, defect)

Not set





(Reporter: jonco, Assigned: jonco)




(1 file)

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/", line 375, in <module>
  File "/builds/slave/try-osx64-d-000000000000000000/build/toolkit/mozapps/installer/", line 367, in main
    args.source, gre_path, base)
  File "/builds/slave/try-osx64-d-000000000000000000/build/toolkit/mozapps/installer/", line 148, in precompile_cache
    errors.fatal('Error while running startup cache precompilation')
  File "/builds/slave/try-osx64-d-000000000000000000/build/python/mozbuild/mozpack/", line 101, in fatal
    self._handle(self.FATAL, msg)
  File "/builds/slave/try-osx64-d-000000000000000000/build/python/mozbuild/mozpack/", 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
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?
Blocks: 905926
Flags: needinfo?(bobbyholley+bmo)
|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.
Flags: needinfo?(bobbyholley+bmo)
(In reply to Bobby Holley (:bholley) from comment #2)

Looks like it's this one:

Stop creating an ephemeral JSContext during XPConnect shutdown
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?
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.
Assignee: general → jcoppeard
Attachment #806782 - Flags: review?(bobbyholley+bmo)
Attachment #806782 - Flags: review?(bobbyholley+bmo) → review+
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
You need to log in before you can comment on or make changes to this bug.