Windows taskcluster builds are broken
Categories
(Webtools :: Searchfox, defect)
Tracking
(firefox67 fixed)
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: kats, Assigned: kats)
References
Details
Attachments
(2 files)
As of recently the windows taskcluster indexing jobs are broken: https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=searchfox&tochange=b641b61da234c8f30ed1e6ea92eabcca53fec0bf&fromchange=0aa259de1b77361ef89c82592b7485f66d4d33fb
Regression range is https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=6b7bc40023111979a4755dfeca82629c9c022cd5 which I'll narrow down more but best guess is bug 1521129.
It looks like one of the js/src/....cpp compilations is hanging. Are you able to run it locally and see which particular source file, and what function in the plugin is stuck? (Or are there instructions on how I could try a local build?)
Assignee | ||
Comment 2•7 years ago
|
||
I don't have access to my Windows machine at the moment so I can't try but you'd need to add these two lines to your mozconfig:
Assignee | ||
Comment 3•7 years ago
•
|
||
Also --enable-debug
since that might be relevant. (edit: and --enable-optimize
)
Assignee | ||
Comment 4•7 years ago
|
||
Confirmed regression range is something in that push (either bug 1521129, bug 1512822, or bug 1522289)
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 6•7 years ago
|
||
This failure mode is kind of ridiculous...
Assignee | ||
Comment 7•7 years ago
•
|
||
Added a printf to see what "P" is at the asserting line...
0:35.40 CXX Destructor char data is [POOLED_COLLECTION_PTR_METHODS(PooledMapPtr, Map)
0:35.40 };
0:35.40 template <typename Vector>
0:35.40 class PooledVectorPtr {
0:35.40 POOLED_COLLECTION_PTR_METHODS(PooledVectorPtr, Vector)
0:35.40 typename Vector::ElementType& operator[](size_t index) {
0:35.40 return collection()[index];
0:35.40 }
0:35.40 const typename Vector::ElementType& operator[](size_t index) const {
0:35.40 return collection()[index];
0:35.40 }
0:35.40 };
0:35.40 #undef POOLED_COLLECTION_PTR_METHODS
0:35.40 } // namespace frontend
0:35.40 } // namespace js
0:35.40 namespace mozilla {
0:35.40 template <typename T>
0:35.40 struct IsPod<js::frontend::RecyclableAtomMapValueWrapper<T>> : IsPod<T> {};
0:35.40 } // namespace mozilla
0:35.40 #endif // frontend_NameCollections_h
0:35.40 ]
So looks like P is pointing to the start of the macro use site at https://searchfox.org/mozilla-central/rev/5c8ea961d04767db723a0a15e3a8f7fbca154129/js/src/frontend/NameCollections.h#282 and the macro expansion is the thing that has the destructor.
Assignee | ||
Comment 8•7 years ago
|
||
I think I have a fix locally. Testing more.
Assignee | ||
Comment 9•7 years ago
|
||
Assignee | ||
Comment 10•7 years ago
|
||
Clang 8 seems to generate destructor decls from different source
locations which breaks an assertion in the code. This patch updates the
code to remove the assertion and more robustly handle the new
declarations.
Comment 11•7 years ago
|
||
Comment 12•7 years ago
|
||
bugherder |
Comment hidden (Intermittent Failures Robot) |
Description
•