Closed Bug 1523082 Opened 7 years ago Closed 7 years ago

Windows taskcluster builds are broken

Categories

(Webtools :: Searchfox, defect)

defect
Not set
normal

Tracking

(firefox67 fixed)

RESOLVED FIXED
Tracking Status
firefox67 --- fixed

People

(Reporter: kats, Assigned: kats)

References

Details

Attachments

(2 files)

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?)

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:

https://searchfox.org/mozilla-central/rev/fbdba3f8185c200279b77b1f5cae4903d5e0a8e0/browser/config/mozconfigs/win64/debug-searchfox#16-17

Also --enable-debug since that might be relevant. (edit: and --enable-optimize)

Attached image Clang failure

This failure mode is kind of ridiculous...

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.

I think I have a fix locally. Testing more.

Assignee: nobody → kats

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.

Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d6305ac9e673 Remove assertion and more robustly handle destructor decls. r=emilio
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: