173720 2017-06-22 09:38:52 -0700 initializeThreading() [first] causes WTFCrash due to maxSingleAllocationSize not being initialized 2017-06-25 14:41:56 -0700 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 vladimir ysuzuki benjamin buildbot cdumez cmarcelo commit-queue darin dbates mark.lam sam ysuzuki oldest_to_newest 1321928 0 vladimir 2017-06-22 09:38:52 -0700 This is probably an edge case, but -- in a JSC static build that gets linked into another DLL, and that DLL does some dumb stuff from static constructors, such as JSClassCreate, I get this crash because maxSingleAllocationSize is still 0 (it's set by Options::initialize() which hasn't been called yet by initializeThreading()) -- lambdas and other junk omitted from stack: WTFCrash() WTF::fastMalloc(unsigned __int64 n) WTF::Lock::operator new(unsigned __int64 size) std::make_unique<WTF::Lock>() WTF::threadMap() WTF::ThreadHolder::initializeOnce() WTF::initializeThreading() JSC::initializeThreading::__l2::<lambda>() JSC::initializeThreading() JSClassCreate(const JSClassDefinition * definition) ... I don't know if this is valid (to do stuff like JSClassCreate from constructors without doing explicit engine initialization), but it worked on older versions of jscore. 1321931 1 vladimir 2017-06-22 09:40:43 -0700 Actually, now that I look closer.. I don't get how it's not initialized to size_t::max(), but is 0, other than static initializer order goop since it's initialized using 'std::numeric_limits<size_t>::max();' ? 1321937 2 vladimir 2017-06-22 09:49:38 -0700 Yep, changing the static initializer to a simple "= SIZE_MAX;" fixes this. 1321939 3 vladimir 2017-06-22 09:59:08 -0700 VS 2017 (cl 19.10.25019). max() is constexpr, so, I dunno why! 1322224 4 ysuzuki 2017-06-23 01:49:39 -0700 (In reply to Vladimir Vukicevic from comment #3) > VS 2017 (cl 19.10.25019). max() is constexpr, so, I dunno why! Hmmmmm, yeah, that is strange. In the meantime, we just use SIZE_MAX. 1322225 5 ysuzuki 2017-06-23 01:51:02 -0700 (In reply to Vladimir Vukicevic from comment #0) > This is probably an edge case, but -- in a JSC static build that gets linked > into another DLL, and that DLL does some dumb stuff from static > constructors, such as JSClassCreate, I get this crash because > maxSingleAllocationSize is still 0 (it's set by Options::initialize() which > hasn't been called yet by initializeThreading()) -- lambdas and other junk > omitted from stack: > > WTFCrash() > WTF::fastMalloc(unsigned __int64 n) > WTF::Lock::operator new(unsigned __int64 size) > std::make_unique<WTF::Lock>() > WTF::threadMap() > WTF::ThreadHolder::initializeOnce() > WTF::initializeThreading() > JSC::initializeThreading::__l2::<lambda>() > JSC::initializeThreading() > JSClassCreate(const JSClassDefinition * definition) > ... > > I don't know if this is valid (to do stuff like JSClassCreate from > constructors without doing explicit engine initialization), but it worked on > older versions of jscore. Basically, we do not allow static constructors in WebKit. If we use static constructors, mac build with clang will fail due to the option restricting static constructors. 1322228 6 313700 ysuzuki 2017-06-23 01:55:39 -0700 Created attachment 313700 Patch 1322725 7 313700 mark.lam 2017-06-25 14:11:53 -0700 Comment on attachment 313700 Patch r=me 1322727 8 313700 ysuzuki 2017-06-25 14:14:29 -0700 Comment on attachment 313700 Patch Thanks! 1322731 9 313700 commit-queue 2017-06-25 14:41:54 -0700 Comment on attachment 313700 Patch Clearing flags on attachment: 313700 Committed r218800: <http://trac.webkit.org/changeset/218800> 1322732 10 commit-queue 2017-06-25 14:41:56 -0700 All reviewed patches have been landed. Closing bug. 313700 2017-06-23 01:55:39 -0700 2017-06-25 14:41:54 -0700 Patch bug-173720-20170623175538.patch text/plain 1689 ysuzuki U3VidmVyc2lvbiBSZXZpc2lvbjogMjE4NzM4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV1RGL0NoYW5n ZUxvZyBiL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCmluZGV4IDMxZjdkNThhOTdlZTg3MTZlYTUzYWIz NjRmMGQzYjAxN2IzMThjMzAuLjRjNDQxNzNkODE3ODBkYTMxMTg1NTJiZDg4N2ZkM2YzOGNlZDNm MmIgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XVEYvQ2hh bmdlTG9nCkBAIC0xLDMgKzEsMTkgQEAKKzIwMTctMDYtMjMgIFl1c3VrZSBTdXp1a2kgIDx1dGF0 YW5lLnRlYUBnbWFpbC5jb20+CisKKyAgICAgICAgaW5pdGlhbGl6ZVRocmVhZGluZygpIFtmaXJz dF0gY2F1c2VzIFdURkNyYXNoIGR1ZSB0byBtYXhTaW5nbGVBbGxvY2F0aW9uU2l6ZSBub3QgYmVp bmcgaW5pdGlhbGl6ZWQKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu Y2dpP2lkPTE3MzcyMAorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisg ICAgICAgIFdoZW4gdXNpbmcgc3RkOjpudW1lcmljX2xpbWl0czxzaXplX3Q+OjptYXgoKSBmb3Ig Z2xvYmFsIHZhcmlhYmxlJ3MgaW5pdGlhbGl6YXRpb24sCisgICAgICAgIGl0IHNlZW1zIHRoYXQg aXQgaW52b2tlcyBzdGF0aWMgY29uc3RydWN0b3IgdG8gaW5pdGlhbGl6ZSB0aGlzIGluIFZDKysu CisgICAgICAgIFdlIGF2b2lkIHRoaXMgZWRnZSBjYXNlIGJ5IGludHJvZHVjaW5nIGEgd29ya2Fy b3VuZCB1c2luZyBTSVpFX01BWCBoZXJlLgorCisgICAgICAgIFdoZW4gSSBwZXJmb3JtIGdpdC1n cmVwLCB0aGVyZSBpcyBvbmx5IG9uZSBzaXRlICh0aGlzKSB1c2luZyBzdGQ6Om51bWVyaWNfbGlt aXRzPD46Onh4eCgpCisgICAgICAgIHRvIGluaXRpYWxpemUgZ2xvYmFsIHZhcmlhYmxlLgorCisg ICAgICAgICogd3RmL0Zhc3RNYWxsb2MuY3BwOgorCiAyMDE3LTA2LTIyICBBbmRyZWFzIEtsaW5n ICA8YWtsaW5nQGFwcGxlLmNvbT4KIAogICAgICAgICBSZW5hbWUgTWVtb3J5UHJlc3N1cmVIYW5k bGVyOjpzZXRUYWJDb3VudCB0byBzZXRQYWdlQ291bnQKZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYv d3RmL0Zhc3RNYWxsb2MuY3BwIGIvU291cmNlL1dURi93dGYvRmFzdE1hbGxvYy5jcHAKaW5kZXgg NDc4YTE5OGVjZDQxYjRmODA2NzIwODJlMGM2NGY0NzQyMGIxYTFiYy4uZmExZDRiMDY1YTc3ZDRl NGE3M2NjOGVlN2FlMmYxOWE0YmMyN2Y4MCAxMDA2NDQKLS0tIGEvU291cmNlL1dURi93dGYvRmFz dE1hbGxvYy5jcHAKKysrIGIvU291cmNlL1dURi93dGYvRmFzdE1hbGxvYy5jcHAKQEAgLTQ4LDcg KzQ4LDkgQEAgbmFtZXNwYWNlIFdURiB7CiAKICNpZiAhZGVmaW5lZChOREVCVUcpCiBuYW1lc3Bh Y2Ugewotc2l6ZV90IG1heFNpbmdsZUFsbG9jYXRpb25TaXplID0gc3RkOjpudW1lcmljX2xpbWl0 czxzaXplX3Q+OjptYXgoKTsKKy8vIFdlIGRvIG5vdCB1c2Ugc3RkOjpudW1lcmljX2xpbWl0czxz aXplX3Q+OjptYXgoKSBoZXJlIGR1ZSB0byB0aGUgZWRnZSBjYXNlIGluIFZDKysuCisvLyBodHRw czovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTczNzIwCitzdGF0aWMgc2l6ZV90 IG1heFNpbmdsZUFsbG9jYXRpb25TaXplID0gU0laRV9NQVg7CiB9OwogCiB2b2lkIGZhc3RTZXRN YXhTaW5nbGVBbGxvY2F0aW9uU2l6ZShzaXplX3Qgc2l6ZSkK