Skip to content

V
V8
Switch branch/tag
  1. 19 Sep, 2014 1 commit
  3. 18 Sep, 2014 2 commits
  5. 16 Sep, 2014 1 commit
  7. 10 Sep, 2014 1 commit
  9. 04 Sep, 2014 1 commit
  11. 02 Sep, 2014 1 commit
  13. 04 Aug, 2014 1 commit
  15. 03 Jun, 2014 2 commits
  17. 29 Apr, 2014 1 commit
  19. 22 Apr, 2014 1 commit
  21. 17 Apr, 2014 1 commit
  23. 11 Apr, 2014 1 commit
  25. 11 Sep, 2013 1 commit
  27. 10 Sep, 2013 1 commit
  29. 23 Aug, 2013 1 commit
    • bmeurer@chromium.org's avatar
      Fix crash due RegExpAtom method called on RegExpCharacterClass object. · 17ec357a
      bmeurer@chromium.org authored 
      In the RegExpUnparser::VisitText(RegExpText* that, void* data) function always RegExpUnparser::VisitAtom function called via that->elements()->at(i).data.u_atom->Accept(this, data); even if the type of the object is RegExpCharacterClass.

The problem shows using g++ 4.7(.2, .3) since r16232, since GCC optimizes virtual method calls to direct calls based on __final/final hints. Tested on MIPS and x64:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000588928 in v8::internal::RegExpUnparser::VisitAtom(v8::internal::RegExpAtom*, void*) ()

This cleans up the TextElement class to avoid the unsafe+unchecked union access, that caused the crash.

TEST=cctest/test-regexp/ParserRegression
R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/22815033

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16289 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      17ec357a
  31. 09 Jul, 2013 1 commit
  33. 26 Jun, 2013 1 commit
  35. 06 Jun, 2013 1 commit
  37. 01 Mar, 2013 1 commit
  39. 06 Feb, 2013 1 commit
  41. 09 Jan, 2013 1 commit
  43. 28 Aug, 2012 1 commit
  45. 21 Aug, 2012 1 commit
  47. 06 Aug, 2012 1 commit
  49. 20 Jun, 2012 1 commit
  51. 14 Jun, 2012 1 commit
  53. 11 Jun, 2012 1 commit
  55. 04 Jun, 2012 1 commit
  57. 01 Jun, 2012 1 commit
  59. 31 May, 2012 1 commit
  61. 22 May, 2012 1 commit
  63. 26 Apr, 2012 1 commit
  65. 24 Apr, 2012 1 commit
  67. 17 Apr, 2012 1 commit
  69. 02 Apr, 2012 1 commit
    • erikcorry's avatar
      Regexp: Improve the speed that we scan for an initial point where a non-anchored · f14b93a5
      erikcorry authored 
      regexp can match by using a Boyer-Moore-like table.  This is done by identifying
non-greedy non-capturing loops in the nodes that eat any character one at a time.
For example in the middle of the regexp /foo[\s\S]*?bar/ we find such a loop.
There is also such a loop implicitly inserted at the start of any non-anchored
regexp.

When we have found such a loop we look ahead in the nodes to find the set of
characters that can come at given distances.  For example for the regexp
/.?foo/ we know that there are at least 3 characters ahead of us, and the sets
of characters that can occur are [any, [f, o], [o]].  We find a range in the
lookahead info where the set of characters is reasonably constrained.  In our
example this is from index 1 to 2 (0 is not constrained).  We can now look 3
characters ahead and if we don't find one of [f, o] (the union of [f, o] and
[o]) then we can skip forwards by the range size (in this case 2).

For Unicode input strings we do the same, but modulo 128.

We also look at the first string fed to the regexp and use that to get a hint
of the character frequencies in the inputs.  This affects the assessment of
whether the set of characters is 'reasonably constrained'.

We still have the old lookahead mechanism, which uses a wide load of multiple
characters followed by a mask and compare to determine whether a match is
possible at this point.
Review URL: http://codereview.chromium.org/9965010

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11204 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      f14b93a5
  71. 28 Feb, 2012 1 commit
  73. 25 Jan, 2012 1 commit
  75. 16 Jan, 2012 1 commit