Use fastMalloc and fastFree instead of malloc and free in RegexInterpreter.cpp's methods.
Created attachment 33870 [details]
Comment on attachment 33870 [details]
Clearing review flag on attachment: 33870
Committing to http://svn.webkit.org/repository/webkit/trunk ...
r46643 = 2fe77a59e15a22979daaf74b11f4283d9b4f2186 (trunk)
No changes between current HEAD and refs/remotes/trunk
Resetting to the latest refs/remotes/trunk
All reviewed patches have been landed. Closing bug.
Unfortunately this change break the v8 tests (as run in the sunspider command-line harness), so reverted for now in r46778.
Can you define "break"? :)
Long hang spinning the cpu, then a crash. Smells like something going off the deep end of the stack, but I'm afraid I don't really have time to debug this regression further right now.
Weird. Was it on a MAC, wasn't it?
It sounds like either the conversion to fastMalloc/fastFree was incomplete here, or that by changing over to fastMalloc we've tripped some other subtle bug in the regexp engine. The latter is bad news and requires further investigation. I worry that the current use of malloc/free could just be papering over some underlying bug, given Gavin's above comment.
It might be worth noting that these mallocs and frees will just go away at some point – these will be replaced with a stack-based allocator, though I don't have a timescale for this right now.
(In reply to comment #7)
> Weird. Was it on a MAC, wasn't it?
This is on Mac, testing the YARR interpreter by setting:
#define ENABLE_YARR 1
#define ENABLE_YARR_JIT 0
These allocations are now stack based, and as such this change is no longer valid.