[Webkit-unassigned] [Bug 183197] [GTK] Crash in WTF::equalIgnoringASCIICaseCommon

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=183197

--- Comment #30 from Michael Catanzaro <mcatanzaro at igalia.com> ---
I went through and added locking all throughout SchemeRegistry.cpp. I'm going to upload a patch, but without r? because it is not good enough.

Problem #1 is SchemeRegistry::isBuiltinScheme, which calls URLParser::isSpecialScheme. After examining the implementation of that function, I think it's actually currently safe, but that's too fragile: it could change in the future, and threadsafe functions should not be calling class static functions, as a rule, unless they're also intended to be threadsafe. Adding locks in SchemeRegistry is fairly easy, but I don't think we want to do so in URLParser, and I'm not sure how to handle this well.

Next problem is that I think our hypothesis in comment #22 is not the only problem here. There is this FIXME you added in SecurityOrigin::shouldTreatAsPotentiallyTrustworthy:

    // FIXME: despite the following SchemeRegistry functions using locks internally, we still
    // have a potential thread-safety issue with the strings being passed in. This is because
    // String::hash() will be called during lookup and it potentially modifies the String for
    // caching the hash.

Looking at the backtrace, I'm fairly confident that is, in fact, the crash we are seeing here. Should we change all of SchemeRegistry to use AtomicString instead of normal String?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180323/a7c21d05/attachment-0001.html>