New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 777177 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Flaky failure in WebGL 2 clipping test, likely v8 related

Project Member Reported by jmad...@chromium.org, Oct 22 2017

Issue description

Flaky builds:

https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28NVIDIA%29/builds/31805
https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28NVIDIA%29/builds/31787

 gpu_tests.webgl_conformance_integration_test.WebGLConformanceIntegrationTest.WebglConformance_deqp_functional_gles3_clipping

Test error text:

#
# Fatal error in ../../v8\src/heap/spaces-inl.h, line 376
# Debug check failed: Page::FromAddress(top()) == Page::FromAddress(top_on_previous_step_) (0BE00000 vs. 0BE80000).
#

Don't know who the sheriffs are right now (build.chromium.org says all are "None"), but hopefully someone from the v8 team can look at this potentially impactful regression.
 

Comment 1 by kbr@chromium.org, Oct 22 2017

Cc: machenb...@chromium.org u...@chromium.org
Components: Blink>JavaScript
Cc: -machenb...@chromium.org mlippautz@chromium.org petermarshall@chromium.org
Components: -Blink>JavaScript -Infra>Client>V8 Blink>JavaScript>GC
Labels: Performance-Memory
Such things are for our memory sheriffs, see http://shortn/_Hc47AAtqXn
Status: Untriaged (was: Available)
Cc: ofrobots@chromium.org
Owner: u...@chromium.org
Status: Assigned (was: Untriaged)
Ulan, any ideas? It looks like the addresses are different pages. Potentially we don't update this properly when switching pages? Also cc'ing Ali who seems to have worked on this part of the code.

Comment 5 by u...@chromium.org, Oct 23 2017

Cc: r...@chromium.org h...@chromium.org thakis@chromium.org
Attaching the minidumps from the crashes. Unfortunately they are unusable because the EIP register is zero and the minidump contains only the stack memory.

rnk@, hans@, thakis@, could the minidump issue be caused by the switch to win clang? Minidumps from webgl bots were working well few weeks ago.

eax=00000000 ebx=00000001 ecx=6639f78e edx=00002042 esi=02050400 edi=0940edd0
eip=00000000 esp=0042d018 ebp=0042d01c iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246


minidump-2017-10-20_15-29-25-67293.dmp
909 KB Download
minidump-2017-10-21_20-47-19-303140.dmp
741 KB Download

Comment 6 by h...@chromium.org, Oct 23 2017

> rnk@, hans@, thakis@, could the minidump issue be caused by the switch to win clang? Minidumps from webgl bots were working well few weeks ago.

No, the switch to win clang was reverted back in August (and I double checked the bots linked in #0 aren't using Clang), so it must be something else.
Awesome, thanks for fixing. I can confirm this is still happening on our waterfall:

https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28NVIDIA%29/builds/31846
Project Member

Comment 9 by bugdroid1@chromium.org, Oct 26 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/7f8f2833663f77d41cdf95b0e2a2a64e844aac7d

commit 7f8f2833663f77d41cdf95b0e2a2a64e844aac7d
Author: Ulan Degenbaev <ulan@chromium.org>
Date: Thu Oct 26 11:10:57 2017

[heap] Fix top_on_previous_step_ check in PagedSpace::AllocateRaw.

Both the top_ pointer and the top_on_previous_step_ pointer can be one
byte beyond the current page. Page::FromAddress call should take that
into account.

Bug:  chromium:777177 
Change-Id: I9cbb5bc6eab932afc6d0c915fd70a9a7b20ba62c
Reviewed-on: https://chromium-review.googlesource.com/738204
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48962}
[modify] https://crrev.com/7f8f2833663f77d41cdf95b0e2a2a64e844aac7d/src/heap/spaces-inl.h
[modify] https://crrev.com/7f8f2833663f77d41cdf95b0e2a2a64e844aac7d/test/cctest/heap/heap-tester.h
[modify] https://crrev.com/7f8f2833663f77d41cdf95b0e2a2a64e844aac7d/test/cctest/heap/test-spaces.cc

Project Member

Comment 10 by bugdroid1@chromium.org, Oct 26 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/d58b36b243fd8e53357d2e9b64e40763e10d8725

commit d58b36b243fd8e53357d2e9b64e40763e10d8725
Author: Ulan Degenbaev <ulan@chromium.org>
Date: Thu Oct 26 14:19:26 2017

[jumbo] Fix collision between test-alloc.cc and test-spaces.cc.

This fixes jumbo build by renaming Pseudorandom function after
https://chromium-review.googlesource.com/738204

Bug:  chromium:777177 
Change-Id: I86aa403928ad85ddd7dd779a8a43af9e34161928
Reviewed-on: https://chromium-review.googlesource.com/737637
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48974}
[modify] https://crrev.com/d58b36b243fd8e53357d2e9b64e40763e10d8725/test/cctest/heap/test-spaces.cc

Comment 11 by u...@chromium.org, Oct 30 2017

Status: Fixed (was: Assigned)

Comment 12 by kbr@chromium.org, Oct 30 2017

Great work Ulan tracking this down from just the couple of reports!

Sign in to add a comment