Skip to content

V
V8
Switch branch/tag
  1. 23 Oct, 2017 1 commit
  3. 20 Oct, 2017 1 commit
  5. 19 Oct, 2017 1 commit
  7. 17 Oct, 2017 2 commits
  9. 16 Oct, 2017 1 commit
  11. 13 Oct, 2017 1 commit
  13. 04 Oct, 2017 2 commits
    • Eric Holk's avatar
      Revert "Reland "[wasm] always allocate memory when guard regions are needed"" · 841ca52c
      Eric Holk authored 
      This reverts commit 5e76ff5a.

Reason for revert: tsan failures - https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/17574

Original change's description:
> Reland "[wasm] always allocate memory when guard regions are needed"
> 
> This reverts commit 7cf29d8d.
> 
> Original change's description:
> > [wasm] always allocate memory when guard regions are needed
> >
> > When using trap handlers, memory references do not get any checks inserted. This
> > means there is no check for a null memory as happens when the memory size is
> > 0. Normally this would be correctly caught as an out of bounds access, since the
> > low memory addresses are not normally mapped. However, if they were mapped for
> > some reason, we would not catch the out of bounds access.
> >
> > The fix is to ensure WebAssembly instances always have a guard region even if
> > the memory is size 0.
> >
> > Bug: chromium:769637
> 
> Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00
> Reviewed-on: https://chromium-review.googlesource.com/695812
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48293}

TBR=gdeepti@chromium.org,mtrofin@chromium.org,mlippautz@chromium.org,eholk@chromium.org,eholk@google.com,clemensh@chromium.org

Change-Id: I52d5354126158a92602b08c48703d562ac95075b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/699599Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48294}
      841ca52c
    • Eric Holk (eholk)'s avatar
      Reland "[wasm] always allocate memory when guard regions are needed" · 5e76ff5a
      Eric Holk (eholk) authored 
      This reverts commit 7cf29d8d.

Original change's description:
> [wasm] always allocate memory when guard regions are needed
>
> When using trap handlers, memory references do not get any checks inserted. This
> means there is no check for a null memory as happens when the memory size is
> 0. Normally this would be correctly caught as an out of bounds access, since the
> low memory addresses are not normally mapped. However, if they were mapped for
> some reason, we would not catch the out of bounds access.
>
> The fix is to ensure WebAssembly instances always have a guard region even if
> the memory is size 0.
>
> Bug: chromium:769637

Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00
Reviewed-on: https://chromium-review.googlesource.com/695812
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48293}
      5e76ff5a
  15. 30 Sep, 2017 1 commit
    • Eric Holk's avatar
      [wasm] set thread-in-wasm flag after converting arguments · 025e3ab1
      Eric Holk authored 
      In JS to Wasm wrappers, arguments have to be converted from JavaScript's
representation to Wasm's representation. Because of property accessors, this can
result in JavaScript or even asm.js/Wasm code being run. We were previously
setting this flag before doing the parameter conversions, and if these
conversions triggered a Wasm property getter then we would try to set the flag
twice.

With this change, we wait until after all argument conversions are done to set
the flag.

Bug: chromium:769846

R=bradnelson@chromium.org

Change-Id: Ia4b56df45619dcad69f3750bb33cacfedcaeb5b2
Reviewed-on: https://chromium-review.googlesource.com/693414
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48244}
      025e3ab1
  17. 29 Sep, 2017 2 commits
    • Eric Holk's avatar
      Revert "[wasm] always allocate memory when guard regions are needed" · 7cf29d8d
      Eric Holk authored 
      This reverts commit 1f99c66b.

Reason for revert: Test timeouts on Win64 Debug: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/19226

Original change's description:
> [wasm] always allocate memory when guard regions are needed
> 
> When using trap handlers, memory references do not get any checks inserted. This
> means there is no check for a null memory as happens when the memory size is
> 0. Normally this would be correctly caught as an out of bounds access, since the
> low memory addresses are not normally mapped. However, if they were mapped for
> some reason, we would not catch the out of bounds access.
> 
> The fix is to ensure WebAssembly instances always have a guard region even if
> the memory is size 0.
> 
> Bug: chromium:769637
> Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
> Reviewed-on: https://chromium-review.googlesource.com/693137
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48240}

TBR=gdeepti@chromium.org,mtrofin@chromium.org,eholk@chromium.org

Change-Id: I4065b367c6cfffe8dd601b67cd53ad54759ae96a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:769637
Reviewed-on: https://chromium-review.googlesource.com/692918Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48242}
      7cf29d8d
    • Eric Holk's avatar
      [wasm] always allocate memory when guard regions are needed · 1f99c66b
      Eric Holk authored 
      When using trap handlers, memory references do not get any checks inserted. This
means there is no check for a null memory as happens when the memory size is
0. Normally this would be correctly caught as an out of bounds access, since the
low memory addresses are not normally mapped. However, if they were mapped for
some reason, we would not catch the out of bounds access.

The fix is to ensure WebAssembly instances always have a guard region even if
the memory is size 0.

Bug: chromium:769637
Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
Reviewed-on: https://chromium-review.googlesource.com/693137Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48240}
      1f99c66b
  19. 20 Sep, 2017 1 commit
  21. 11 Sep, 2017 1 commit
  23. 05 Sep, 2017 1 commit
  25. 24 Aug, 2017 1 commit
  27. 10 Aug, 2017 1 commit
  29. 09 Aug, 2017 1 commit
  31. 26 Jul, 2017 1 commit
  33. 14 Jul, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Update signature map on indirect calls · 883db26e
      Clemens Hammacher authored 
      The code was already there, but there was a bug in it: Because of the
missing reference, we were only updating a *copy* of the signature map,
hence the update had no effect.
This intentially is a minimal CL, in order to allow for easy
backmerging.
More mitigations and tests are coming in a separate CL.

R=titzer@chromium.org

Change-Id: Ifb462093f4b8f4d5380b6774636537c67c2b676c
Reviewed-on: https://chromium-review.googlesource.com/570278Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46664}
      883db26e
  35. 13 Jul, 2017 1 commit
  37. 30 Jun, 2017 2 commits
    • Andreas Haas's avatar
      Revert "[wasm] Run foreground compilation tasks as normal tasks" · 89154bf6
      Andreas Haas authored 
      This reverts commit 1520a851.

Reason for revert: This CL does not do what it should. All tasks which access the isolate have to be cancelable to guarantee that the isolate still exists when the task is executed. Foreground compilation tasks access the isolate, so they cannot be just normal tasks.

Original change's description:
> [wasm] Run foreground compilation tasks as normal tasks
> 
> This CL makes foreground compilation tasks normal (i.e. not cancelable)
> again, because otherwise a deadlock can happen. I think the reason why
> the foreground tasks were cancelable was to make sure that all tasks
> either finish correctly or get canceled. However, since the isolate can
> only shut down on the main thread, this means that the foreground task
> should have already finished when the isolate shuts down, or it should
> not have started at all. I reordered the deletion of the AsyncCompileJob
> though to make sure that an AsyncCompileJob is removed from
> CompilationManager before its promise is resolved.
> 
> Here is the deadlock: The JS code which is executed after a promise is
> resolved is executed within the task which resolves the promise. In case
> of async compilation this means that some JS code is executed within a
> CompileTask. In JS, the shutdown of the isolate can be triggered. During
> the shutdown of the isolate, the CancelableTaskManager waits for all
> registered cancelable tasks to complete, including the CompileTask of
> async compilation. This means that the CancelableTaskManager waits for
> itself to finish, which is a deadlock.
> 
> R=​clemensh@chromium.org, mtrofin@chromium.org
> 
> Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
> Reviewed-on: https://chromium-review.googlesource.com/554733
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46343}

TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org

Change-Id: I60fab90b46d70c703d827816503e7e23b8c50251
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558284Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46353}
      89154bf6
    • Andreas Haas's avatar
      [wasm] Run foreground compilation tasks as normal tasks · 1520a851
      Andreas Haas authored 
      This CL makes foreground compilation tasks normal (i.e. not cancelable)
again, because otherwise a deadlock can happen. I think the reason why
the foreground tasks were cancelable was to make sure that all tasks
either finish correctly or get canceled. However, since the isolate can
only shut down on the main thread, this means that the foreground task
should have already finished when the isolate shuts down, or it should
not have started at all. I reordered the deletion of the AsyncCompileJob
though to make sure that an AsyncCompileJob is removed from
CompilationManager before its promise is resolved.

Here is the deadlock: The JS code which is executed after a promise is
resolved is executed within the task which resolves the promise. In case
of async compilation this means that some JS code is executed within a
CompileTask. In JS, the shutdown of the isolate can be triggered. During
the shutdown of the isolate, the CancelableTaskManager waits for all
registered cancelable tasks to complete, including the CompileTask of
async compilation. This means that the CancelableTaskManager waits for
itself to finish, which is a deadlock.

R=clemensh@chromium.org, mtrofin@chromium.org

Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
Reviewed-on: https://chromium-review.googlesource.com/554733
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46343}
      1520a851
  39. 28 Jun, 2017 1 commit
  41. 26 Jun, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Fix wrong implication · 08fc24b9
      Clemens Hammacher authored 
      The implication was actually in the wrong direction: If there is no
memory start address, then the size must be 0.
If the size is 0 though, we might allocate nevertheless to have guard
pages around the accessible memory.

R=ahaas@chromium.org
BUG=chromium:736584

Change-Id: I297dece658d5eaf69c58ecb109ff21d3ca0b8a8d
Reviewed-on: https://chromium-review.googlesource.com/548635Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46221}
      08fc24b9
  43. 20 Jun, 2017 3 commits
  45. 13 Jun, 2017 1 commit
  47. 06 Jun, 2017 1 commit
  49. 01 Jun, 2017 1 commit
  51. 30 May, 2017 1 commit
  53. 29 May, 2017 1 commit
  55. 23 May, 2017 1 commit
  57. 22 May, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Stricter max memory check · a5449b0f
      Clemens Hammacher authored 
      If the maximum number of memory pages is raised using
--wasm-max-mem-pages, we might allocate more than kMaxInt bytes for
wasm memory. The byte length is stored as int in JSArrayBuffer, hence
this can lead to failures.
Thus, we now additially check against kMaxInt, and fail instantiation
if this check fails.

Drive-by: Add/fix more bounds checks.

R=ahaas@chromium.org
BUG=chromium:724846

Change-Id: Id8e1a1e13e15f4aa355ab9414b4b950510e5e88a
Reviewed-on: https://chromium-review.googlesource.com/509255Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45465}
      a5449b0f
  59. 17 May, 2017 2 commits
    • Clemens Hammacher's avatar
      [wasm] Check for illegal br table count · 74519c43
      Clemens Hammacher authored 
      The underlying issue is that TF Nodes cannot handle input counts
outside the integer range. On an illegal br_table instruction, we
generated a switch node with a control output count >kMaxInt.
Operator::ControlOutputCount turned this into a negative integer later,
leading to a failing DCHECK.
Since such large numbers cannot occur in any valid wasm function anyway,
we just add an additional check to the br table count. There is already
a TODO in the code to change Operator::ControlOutputCount to size_t.

R=ahaas@chromium.org
BUG=chromium:722445

Change-Id: I1975072226e073dee6c8da3b9fa9a050a4695917
Reviewed-on: https://chromium-review.googlesource.com/505496Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45365}
      74519c43
    • Clemens Hammacher's avatar
      [wasm] Don't try to interpret asm.js modules · a68b75d0
      Clemens Hammacher authored 
      The interpreter does not implement all asm.js specific opcodes. Thus
the combination of --validate-asm and --wasm-interpret-all might crash.
The interpreter does not need to execute asm.js  modules, as they are
debugged by executing them in turbofan instead of the wasm interpreter.
This CL thus excludes asm.js modules from --wasm-interpret-all.

R=ahaas@chromium.org
BUG=chromium:719175

Change-Id: I14228ea11ee3ea8a229cfa6e4179338a442b6cca
Reviewed-on: https://chromium-review.googlesource.com/506160
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45364}
      a68b75d0
  61. 04 May, 2017 1 commit
  63. 03 May, 2017 1 commit
  65. 02 May, 2017 1 commit