1060995 - Mac Xulrunner build broken with "ld: bad codegen, pointer diff in __ZN21XPCWrappedNativeScopeC2EP9JSContextN2JS6HandleIP8JSObjectEE"

Status: RESOLVED DUPLICATE of bug 1081031

(Core :: XPConnect, defect)

Description

[Phil Ringnalda (:philor)]

A lovely state of affairs:

* we only run Xulrunner as hidden nightly builds, only on mozilla-central and mozilla-aurora, so nobody ever looks at them

* Xulrunner is a release deliverable, so despite it being tier-2, it's also as tier-1 as tier-1 can be

* as of July 21st, when we last merged to mozilla-aurora, the Mac Xulrunner builds were dying with bug 1060984

* as of July 30th, currently the oldest log which has not been purged, they were dying like they currently are (https://tbpl.mozilla.org/php/getParsedLog.php?id=47126659&tree=Mozilla-Central for the latest log), so somewhere in the first 9 days of Gecko 34 this earlier-in-the-build bustage landed

ld: bad codegen, pointer diff in __ZN21XPCWrappedNativeScopeC2EP9JSContextN2JS6HandleIP8JSObjectEE to global weak symbol __ZTVN2JS10WeakMapPtrIP8JSObjectS2_EE for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)


[Tracking Requested - why for this release]:
Xulrunner is a release deliverable, unless we complete bug 672509 on Gecko 34 before it hits beta.

Comment 1

[Benjamin Smedberg]

vtable for JS::WeakMapPtr<JSObject*, JSObject*>

Are we using static JS in xulrunner builds? JS_PUBLIC_API for a template seems really fragile to me. Note that the vtable is emitted along with the first non-inline method, which in this case is WeakMapPtr::Init, and although that is explicitly instantiated at the end of WeakMapPtr.cpp, I bet the linker is allowed to strip it from a shared library if it is unreferenced.

Comment 2

[Bobby Holley (:bholley)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> Are we using static JS in xulrunner builds? JS_PUBLIC_API for a template
> seems really fragile to me. Note that the vtable is emitted along with the
> first non-inline method, which in this case is WeakMapPtr::Init, and
> although that is explicitly instantiated at the end of WeakMapPtr.cpp, I bet
> the linker is allowed to strip it from a shared library if it is
> unreferenced.

This has been in the tree since February. Is the issue that the compiler is just non-deterministically stripping the symbol? Are there any hacks we can use to force the compiler to keep it around? In general we use loads of templates from JSAPI. And the configuration triggering this is going away soonish right?

Comment 3

[Benjamin Smedberg]

I tried a local (non-unified) opt build of XULRunner and couldn't reproduce this. Is a unified or x86 build required to reproduce?

Comment 4

[:Gijs (he/him)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #3)
> I tried a local (non-unified) opt build of XULRunner and couldn't reproduce
> this. Is a unified or x86 build required to reproduce?

Presumably, because the error message refers to:

ld: bad codegen, pointer diff in __ZN21XPCWrappedNativeScopeC2EP9JSContextN2JS6HandleIP8JSObjectEE to global weak symbol __ZTVN2JS10WeakMapPtrIP8JSObjectS2_EE for architecture i386

Comment 5

[Phil Ringnalda (:philor)]

Fixed in bug 1081031