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.
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();' ?
Yep, changing the static initializer to a simple "= SIZE_MAX;" fixes this.
VS 2017 (cl 19.10.25019). max() is constexpr, so, I dunno why!
(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.
(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.
Created attachment 313700 [details] Patch
Comment on attachment 313700 [details] Patch r=me
Comment on attachment 313700 [details] Patch Thanks!
Comment on attachment 313700 [details] Patch Clearing flags on attachment: 313700 Committed r218800: <http://trac.webkit.org/changeset/218800>
All reviewed patches have been landed. Closing bug.