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

Issue 831501 link

Starred by 6 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Crash in v8::internal::Heap::ProtectUnprotectedMemoryChunks()

Project Member Reported by yangguo@chromium.org, Apr 11 2018

Issue description

Repro:
- Check out Chromium at a5439425dd127207c2fec3f358d1f329428d0b71
- Build in release mode (Linux)
- Open https://mobile.twitter.com/hashseed
- Open DevTools
- Select mobile view (top left corner)
- Scroll up and down repeatedly. This can take 10-20 seconds.
- Observe crash

#
# Fatal error in , line 0
# Check failed: memory_allocator()->IsMemoryChunkExecutable(*chunk).
#
#
#
#FailureMessage Object: 0x7f2e29e6cb00#0 0x56275d92741c base::debug::StackTrace::StackTrace()
#1 0x56275fd8c32b gin::(anonymous namespace)::PrintStackTrace()
#2 0x56275fd85178 V8_Fatal()
#3 0x56275d0a5f5f v8::internal::Heap::ProtectUnprotectedMemoryChunks()
#4 0x56275d08c531 v8::internal::Factory::NewCode()
#5 0x56275d41565c v8::internal::RegExpMacroAssemblerX64::GetCode()
#6 0x56275d263204 v8::internal::RegExpCompiler::Assemble()
#7 0x56275d261cf4 v8::internal::RegExpEngine::Compile()
#8 0x56275d26107d v8::internal::RegExpImpl::CompileIrregexp()
#9 0x56275d260a75 v8::internal::RegExpImpl::IrregexpExec()
#10 0x56275d30667c v8::internal::Runtime_RegExpExec()
#11 0x0186f12841dd <unknown>
Received signal 4 ILL_ILLOPN 56275fd871d2
#0 0x56275d92741c base::debug::StackTrace::StackTrace()
#1 0x56275d926f81 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f2e402040c0 <unknown>
#3 0x56275fd871d2 v8::base::OS::Abort()
#4 0x56275d0a5f5f v8::internal::Heap::ProtectUnprotectedMemoryChunks()
#5 0x56275d08c531 v8::internal::Factory::NewCode()
#6 0x56275d41565c v8::internal::RegExpMacroAssemblerX64::GetCode()
#7 0x56275d263204 v8::internal::RegExpCompiler::Assemble()
#8 0x56275d261cf4 v8::internal::RegExpEngine::Compile()
#9 0x56275d26107d v8::internal::RegExpImpl::CompileIrregexp()
#10 0x56275d260a75 v8::internal::RegExpImpl::IrregexpExec()
#11 0x56275d30667c v8::internal::Runtime_RegExpExec()
#12 0x0186f12841dd <unknown>
  r8: 00007f2e3a61f750  r9: 00007f2e29e70700 r10: 0000000000000003 r11: 0000000000000000
 r12: 0000562759c1f8bf r13: 00007f2e29e6cfc0 r14: 0000000000000000 r15: 0000562759ce18fd
  di: 00007f2e3a61e520  si: 00007f2e3a61f750  bp: 00007f2e29e6d000  bx: 00007f2e3a61e6e0
  dx: 0000000000000000  ax: 0000000000000000  cx: 0000000000000b40  sp: 00007f2e29e6caf8
  ip: 000056275fd871d2 efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000006 msk: 0000000000000000 cr2: 0000000000000000

 
Cc: mlippautz@chromium.org
I added some printf. The value for *chunk at the check is nil.

Comment 3 by hpayer@chromium.org, Apr 11 2018

Cc: jkummerow@chromium.org
Hi Jakob, that broke with the factory clean-up.

The two unprotect scopes for chunks and spaces have to work together now which was prohibited before.
Found the issue.

A MemoryChunk is released in MemoryChunk::ReleaseAllocatedMemory while it's still registered in unprotected_memory_chunks_. When we call Heap::ProtectUnprotectedMemoryChunks, we use that already free'ed chunk and crash.

Comment 5 by hpayer@chromium.org, Apr 11 2018

Status: Started (was: Assigned)
These are the issues if we allow overlapping of CodeSpaceMemoryModificationScope and CodePageCollectionMemoryModificationScope. Let's enumerate all possibilities:

1) CodePageCollectionMemoryModificationScope is open and CodeSpaceMemoryModificationScope is opened later (we do a code allocation that triggers GC):
1.1 GC frees a page that was already registered with CodePageCollectionMemoryModificationScope. The freed page will not be valid when we later try to switch w->x. (This is the bug Yang observed.)
1.2 Leaving the CodeSpaceMemoryModificationScope will make all code pages x. Later initialization of the object should crash.
2) CodeSpaceMemoryModificationScope is open and CodePageCollectionMemoryModificationScope is opened later: We don't allow that.

Comment 6 by hpayer@chromium.org, Apr 11 2018

Cc: mstarzinger@chromium.org

Comment 7 by habl...@google.com, Apr 11 2018

Issue 831533 has been merged into this issue.

Comment 8 by habl...@google.com, Apr 11 2018

Components: Blink>JavaScript>GC
Labels: -Type-Bug -Pri-3 M-67 ReleaseBlock-Beta Pri-1 Type-Bug-Regression

Comment 9 by hpayer@chromium.org, Apr 11 2018

1.2 works because we have write_unprotect_counter_ on the page.
I can no longer reproduce the crash with this fix: https://chromium-review.googlesource.com/c/v8/v8/+/1006755
Project Member

Comment 11 by bugdroid1@chromium.org, Apr 11 2018

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

commit 3e7b7ed24abdaf2925f55d54f420fe256d50de74
Author: Hannes Payer <hpayer@chromium.org>
Date: Wed Apr 11 11:54:17 2018

[heap] Remove MemoryChunks from CodePageCollectionMemoryModificationScope set if they get freed.

Bug: chromium:831501 
Change-Id: I82daa3dc1a6cc08cb63e42f4a54b69d28303ce0f

NOTREECHECKS=true

Change-Id: I82daa3dc1a6cc08cb63e42f4a54b69d28303ce0f
Reviewed-on: https://chromium-review.googlesource.com/1006755
Commit-Queue: Michael Hablich <hablich@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52546}
[modify] https://crrev.com/3e7b7ed24abdaf2925f55d54f420fe256d50de74/src/heap/heap.cc
[modify] https://crrev.com/3e7b7ed24abdaf2925f55d54f420fe256d50de74/src/heap/heap.h
[modify] https://crrev.com/3e7b7ed24abdaf2925f55d54f420fe256d50de74/src/heap/spaces.h

Status: Fixed (was: Started)
The fix is now rolling into Chromium: https://chromium-review.googlesource.com/c/chromium/src/+/1007158
 Issue 831584  has been merged into this issue.
Project Member

Comment 15 by ClusterFuzz, Apr 11 2018

Labels: OS-Linux
Project Member

Comment 16 by ClusterFuzz, Apr 12 2018

Labels: ClusterFuzz-Verified
Status: Verified (was: Fixed)
ClusterFuzz testcase 6566953431597056 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
Cc: hpayer@chromium.org kbr@chromium.org
 Issue 831318  has been merged into this issue.

Sign in to add a comment