WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
198063
Cleanup Yarr regexp code around paren contexts.
https://bugs.webkit.org/show_bug.cgi?id=198063
Summary
Cleanup Yarr regexp code around paren contexts.
Keith Miller
Reported
2019-05-20 18:43:10 PDT
Cleanup Yarr regexp code around paren contexts.
Attachments
Patch
(15.59 KB, patch)
2019-05-20 19:47 PDT
,
Keith Miller
ysuzuki
: review+
ews-watchlist
: commit-queue-
Details
Formatted Diff
Diff
Archive of layout-test-results from ews211 for win-future
(13.82 MB, application/zip)
2019-05-21 00:23 PDT
,
EWS Watchlist
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Keith Miller
Comment 1
2019-05-20 19:47:49 PDT
Created
attachment 370294
[details]
Patch
Yusuke Suzuki
Comment 2
2019-05-20 21:43:19 PDT
Comment on
attachment 370294
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=370294&action=review
Nice, r=me
> Source/JavaScriptCore/runtime/RegExpInlines.h:118 > bool m_needBuffer;
Do we need this m_needBuffer field? I think if this is true, m_buffer needs to be non nullptr. And if this is false, m_buffer is nullptr.
> Source/JavaScriptCore/runtime/RegExpInlines.h:119 > void* m_buffer;
I think adding `{ nullptr }` here is better. Otherwise, when `ENABLE(YARR_JIT_ALL_PARENS_EXPRESSIONS)` is false, this m_buffer is left as uninitialized. It is OK so long as we don't use it actually. But touching `m_buffer` in `size()` is a bit scary :)
Yusuke Suzuki
Comment 3
2019-05-20 21:46:42 PDT
Comment on
attachment 370294
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=370294&action=review
> Source/JavaScriptCore/yarr/YarrJIT.h:60 > + // Technically freeParenContext and parenContextSize are only used if ENABLE(YARR_JIT_ALL_PARENS_EXPRESSIONS) is set. Fortunately, all the calling conventions we supporthave caller save argument registers.
supporthave => support have It is nice if we can ensure this with static_assert.
EWS Watchlist
Comment 4
2019-05-21 00:23:33 PDT
Comment on
attachment 370294
[details]
Patch
Attachment 370294
[details]
did not pass win-ews (win): Output:
https://webkit-queues.webkit.org/results/12243064
New failing tests: imported/blink/fast/canvas/canvas-clip-stack-persistence.html http/tests/security/canvas-remote-read-remote-video-redirect.html fast/shadow-dom/svg-use-href-change-in-shadow-tree.html http/tests/security/contentSecurityPolicy/video-with-https-url-allowed-by-csp-media-src-star.html http/tests/security/contentSecurityPolicy/video-with-http-url-allowed-by-csp-media-src-star.html imported/blink/fast/canvas/bug382588.html
EWS Watchlist
Comment 5
2019-05-21 00:23:36 PDT
Created
attachment 370301
[details]
Archive of layout-test-results from ews211 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews211 Port: win-future Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit
Keith Miller
Comment 6
2019-05-21 10:40:03 PDT
Comment on
attachment 370294
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=370294&action=review
>> Source/JavaScriptCore/runtime/RegExpInlines.h:118 >> bool m_needBuffer; > > Do we need this m_needBuffer field? I think if this is true, m_buffer needs to be non nullptr. And if this is false, m_buffer is nullptr.
Not really but it's only ever stack allocated. I should add WTF_FORBID_HEAP_ALLOCATION... I'll make that change though.
>> Source/JavaScriptCore/runtime/RegExpInlines.h:119 >> void* m_buffer; > > I think adding `{ nullptr }` here is better. Otherwise, when `ENABLE(YARR_JIT_ALL_PARENS_EXPRESSIONS)` is false, this m_buffer is left as uninitialized. > It is OK so long as we don't use it actually. But touching `m_buffer` in `size()` is a bit scary :)
True will change! I think I accidentally removed that during some cleanup.
>> Source/JavaScriptCore/yarr/YarrJIT.h:60 >> + // Technically freeParenContext and parenContextSize are only used if ENABLE(YARR_JIT_ALL_PARENS_EXPRESSIONS) is set. Fortunately, all the calling conventions we supporthave caller save argument registers. > > supporthave => support have > It is nice if we can ensure this with static_assert.
Fixed. I don't know of a way to do that static_assert though. :/
Keith Miller
Comment 7
2019-05-21 10:40:57 PDT
It's weird that EWS says this breaks tests but the bubble is green... and the history there says it passed. O.o
Keith Miller
Comment 8
2019-05-21 10:57:18 PDT
Committed
r245586
: <
https://trac.webkit.org/changeset/245586
>
Radar WebKit Bug Importer
Comment 9
2019-05-21 10:59:45 PDT
<
rdar://problem/50991840
>
Shawn Roberts
Comment 10
2019-05-21 13:29:42 PDT
After changes in
https://trac.webkit.org/changeset/245586
OpenSource testers are exiting early with 50 crashes. First iOS Debug exit:
https://build.webkit.org/builders/Apple%20iOS%2012%20Simulator%20Debug%20WK2%20%28Tests%29/builds/3806
First Mac Release exit:
https://build.webkit.org/builders/Apple%20Mojave%20Release%20WK2%20%28Tests%29/builds/4239
Debug crashes give the following assertion. ASSERTION FAILED: m_regExpPatternContextLock.isLocked() ./runtime/VM.cpp(958) : void JSC::VM::releaseRegExpPatternContexBuffer() 1 0x5408285e9 WTFCrash 2 0x54082b3ab WTFCrashWithInfo(int, char const*, char const*, int) 3 0x541b84ee4 JSC::VM::releaseRegExpPatternContexBuffer() 4 0x541251e4f JSC::PatternContextBufferHolder::~PatternContextBufferHolder() 5 0x5412515e5 JSC::PatternContextBufferHolder::~PatternContextBufferHolder() 6 0x541adc80e int JSC::RegExp::matchInline<WTF::Vector<int, 0ul, WTF::CrashOnOverflow, 16ul> >(JSC::VM&, WTF::String const&, unsigned int, WTF::Vector<int, 0ul, WTF::CrashOnOverflow, 16ul>&) 7 0x541adc403 JSC::RegExp::match(JSC::VM&, WTF::String const&, unsigned int, WTF::Vector<int, 0ul, WTF::CrashOnOverflow, 16ul>&) 8 0x541b3821a JSC::RegExpGlobalData::performMatch(JSC::VM&, JSC::JSGlobalObject*, JSC::RegExp*, JSC::JSString*, WTF::String const&, int, int**) 9 0x541b2761f JSC::replaceUsingRegExpSearch(JSC::VM&, JSC::ExecState*, JSC::JSString*, JSC::JSValue, JSC::CallData&, JSC::CallType, WTF::String&, JSC::JSValue) 10 0x541b288f4 JSC::replaceUsingRegExpSearch(JSC::VM&, JSC::ExecState*, JSC::JSString*, JSC::JSValue, JSC::JSValue) 11 0x541b2391b JSC::stringProtoFuncReplaceUsingRegExp(JSC::ExecState*)
Saam Barati
Comment 11
2019-05-27 23:52:32 PDT
(In reply to Shawn Roberts from
comment #10
)
> After changes in
https://trac.webkit.org/changeset/245586
> > OpenSource testers are exiting early with 50 crashes. > > First iOS Debug exit: >
https://build.webkit.org/builders/
> Apple%20iOS%2012%20Simulator%20Debug%20WK2%20%28Tests%29/builds/3806 > > First Mac Release exit: >
https://build.webkit.org/builders/
> Apple%20Mojave%20Release%20WK2%20%28Tests%29/builds/4239 > > Debug crashes give the following assertion. > > ASSERTION FAILED: m_regExpPatternContextLock.isLocked() > ./runtime/VM.cpp(958) : void JSC::VM::releaseRegExpPatternContexBuffer() > 1 0x5408285e9 WTFCrash > 2 0x54082b3ab WTFCrashWithInfo(int, char const*, char const*, int) > 3 0x541b84ee4 JSC::VM::releaseRegExpPatternContexBuffer() > 4 0x541251e4f > JSC::PatternContextBufferHolder::~PatternContextBufferHolder() > 5 0x5412515e5 > JSC::PatternContextBufferHolder::~PatternContextBufferHolder() > 6 0x541adc80e int JSC::RegExp::matchInline<WTF::Vector<int, 0ul, > WTF::CrashOnOverflow, 16ul> >(JSC::VM&, WTF::String const&, unsigned int, > WTF::Vector<int, 0ul, WTF::CrashOnOverflow, 16ul>&) > 7 0x541adc403 JSC::RegExp::match(JSC::VM&, WTF::String const&, unsigned > int, WTF::Vector<int, 0ul, WTF::CrashOnOverflow, 16ul>&) > 8 0x541b3821a JSC::RegExpGlobalData::performMatch(JSC::VM&, > JSC::JSGlobalObject*, JSC::RegExp*, JSC::JSString*, WTF::String const&, int, > int**) > 9 0x541b2761f JSC::replaceUsingRegExpSearch(JSC::VM&, JSC::ExecState*, > JSC::JSString*, JSC::JSValue, JSC::CallData&, JSC::CallType, WTF::String&, > JSC::JSValue) > 10 0x541b288f4 JSC::replaceUsingRegExpSearch(JSC::VM&, JSC::ExecState*, > JSC::JSString*, JSC::JSValue, JSC::JSValue) > 11 0x541b2391b JSC::stringProtoFuncReplaceUsingRegExp(JSC::ExecState*)
Is this fixed?
Yusuke Suzuki
Comment 12
2019-05-28 02:03:56 PDT
(In reply to Saam Barati from
comment #11
)
> (In reply to Shawn Roberts from
comment #10
) > > After changes in
https://trac.webkit.org/changeset/245586
> > > > OpenSource testers are exiting early with 50 crashes. > > > > First iOS Debug exit: > >
https://build.webkit.org/builders/
> > Apple%20iOS%2012%20Simulator%20Debug%20WK2%20%28Tests%29/builds/3806 > > > > First Mac Release exit: > >
https://build.webkit.org/builders/
> > Apple%20Mojave%20Release%20WK2%20%28Tests%29/builds/4239 > > > > Debug crashes give the following assertion. > > > > ASSERTION FAILED: m_regExpPatternContextLock.isLocked() > > ./runtime/VM.cpp(958) : void JSC::VM::releaseRegExpPatternContexBuffer() > > 1 0x5408285e9 WTFCrash > > 2 0x54082b3ab WTFCrashWithInfo(int, char const*, char const*, int) > > 3 0x541b84ee4 JSC::VM::releaseRegExpPatternContexBuffer() > > 4 0x541251e4f > > JSC::PatternContextBufferHolder::~PatternContextBufferHolder() > > 5 0x5412515e5 > > JSC::PatternContextBufferHolder::~PatternContextBufferHolder() > > 6 0x541adc80e int JSC::RegExp::matchInline<WTF::Vector<int, 0ul, > > WTF::CrashOnOverflow, 16ul> >(JSC::VM&, WTF::String const&, unsigned int, > > WTF::Vector<int, 0ul, WTF::CrashOnOverflow, 16ul>&) > > 7 0x541adc403 JSC::RegExp::match(JSC::VM&, WTF::String const&, unsigned > > int, WTF::Vector<int, 0ul, WTF::CrashOnOverflow, 16ul>&) > > 8 0x541b3821a JSC::RegExpGlobalData::performMatch(JSC::VM&, > > JSC::JSGlobalObject*, JSC::RegExp*, JSC::JSString*, WTF::String const&, int, > > int**) > > 9 0x541b2761f JSC::replaceUsingRegExpSearch(JSC::VM&, JSC::ExecState*, > > JSC::JSString*, JSC::JSValue, JSC::CallData&, JSC::CallType, WTF::String&, > > JSC::JSValue) > > 10 0x541b288f4 JSC::replaceUsingRegExpSearch(JSC::VM&, JSC::ExecState*, > > JSC::JSString*, JSC::JSValue, JSC::JSValue) > > 11 0x541b2391b JSC::stringProtoFuncReplaceUsingRegExp(JSC::ExecState*) > > Is this fixed?
Yes, this is fixed in
http://trac.webkit.org/changeset/245593/webkit
Michael Catanzaro
Comment 13
2019-06-24 12:52:45 PDT
Note we're considering rolling this out in
bug #198518
since some of the assumptions regarding MatchResult and EncodedMatchResult were wrong and the fix is unclear. Would be great to get your help there.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug