587495 - Extended regular expressions trash parameter memory

Status: RESOLVED DUPLICATE of bug 588273

(Core :: JavaScript Engine, defect)

Description

[[e-mail]]

Steps to reproduce problem:
Evaluate any or all of the following in 64-bit js.exe:
/(?:)/.test('test1'); 'test1';
/(?=)/.test('test2'); 'test2';
/(?!!)/.test('test3'); 'test3';
Expected result: test1 test2 test3
Actual result: first four letters filled with garbage
Additional information:
/(?::)/.test('test4'); only fills two letters with garbage
/(?==)/ and /(?!)/ do not trash their parameter

Comment 1

[Chris Leary [:cdleary] (not checking bugmail)]

I can't repro on 64b Linux -- I think 64b PCRE may be what's screwing up here. /me shuffles stuff around to find his 64b windows VM...

Comment 2

[Chris Leary [:cdleary] (not checking bugmail)]

Sorry, wasn't specific -- I think it's PCRE on 64b Windows, since we don't use the computed goto paths there. Had to set up my 64b windows VM tonight, will check it out tomorrow morn'.

Comment 3

[[e-mail]]

It occurred to me that I could set a data breakpoint on the string memory. Having done this the breakpoint triggered in a RegexJITCode block called from JSC::Yarr::RegexCodeBlock::execute.

And looking at the disassembly I notice that the JIT is using the GCC calling convention of rdi, esi, edx, rcx but MSVC wants rcx, edx, r8d, r9...

I'm not sure what the best way of detecting for MSVC is, so I just tweaked my copy of RegexJIT.cpp to uncondtionally use the MSVC calling convention, and it seems to fix the issue.

Comment 4

[Robert Sayre]

blocking final+ assuming this is Win64 only

Comment 5

[:Gavin Sharp [email: [e-mail]]]

fixed by bug 588273?

Comment 6

[[e-mail]]

Indeed; thanks, Gavin.