<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>[181457] trunk/Source/bmalloc</title>
</head>
<body>

<style type="text/css"><!--
#msg dl.meta { border: 1px #006 solid; background: #369; padding: 6px; color: #fff; }
#msg dl.meta dt { float: left; width: 6em; font-weight: bold; }
#msg dt:after { content:':';}
#msg dl, #msg dt, #msg ul, #msg li, #header, #footer, #logmsg { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt;  }
#msg dl a { font-weight: bold}
#msg dl a:link    { color:#fc3; }
#msg dl a:active  { color:#ff0; }
#msg dl a:visited { color:#cc6; }
h3 { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; font-weight: bold; }
#msg pre { overflow: auto; background: #ffc; border: 1px #fa0 solid; padding: 6px; }
#logmsg { background: #ffc; border: 1px #fa0 solid; padding: 1em 1em 0 1em; }
#logmsg p, #logmsg pre, #logmsg blockquote { margin: 0 0 1em 0; }
#logmsg p, #logmsg li, #logmsg dt, #logmsg dd { line-height: 14pt; }
#logmsg h1, #logmsg h2, #logmsg h3, #logmsg h4, #logmsg h5, #logmsg h6 { margin: .5em 0; }
#logmsg h1:first-child, #logmsg h2:first-child, #logmsg h3:first-child, #logmsg h4:first-child, #logmsg h5:first-child, #logmsg h6:first-child { margin-top: 0; }
#logmsg ul, #logmsg ol { padding: 0; list-style-position: inside; margin: 0 0 0 1em; }
#logmsg ul { text-indent: -1em; padding-left: 1em; }#logmsg ol { text-indent: -1.5em; padding-left: 1.5em; }
#logmsg > ul, #logmsg > ol { margin: 0 0 1em 0; }
#logmsg pre { background: #eee; padding: 1em; }
#logmsg blockquote { border: 1px solid #fa0; border-left-width: 10px; padding: 1em 1em 0 1em; background: white;}
#logmsg dl { margin: 0; }
#logmsg dt { font-weight: bold; }
#logmsg dd { margin: 0; padding: 0 0 0.5em 0; }
#logmsg dd:before { content:'\00bb';}
#logmsg table { border-spacing: 0px; border-collapse: collapse; border-top: 4px solid #fa0; border-bottom: 1px solid #fa0; background: #fff; }
#logmsg table th { text-align: left; font-weight: normal; padding: 0.2em 0.5em; border-top: 1px dotted #fa0; }
#logmsg table td { text-align: right; border-top: 1px dotted #fa0; padding: 0.2em 0.5em; }
#logmsg table thead th { text-align: center; border-bottom: 1px solid #fa0; }
#logmsg table th.Corner { text-align: left; }
#logmsg hr { border: none 0; border-top: 2px dashed #fa0; height: 1px; }
#header, #footer { color: #fff; background: #636; border: 1px #300 solid; padding: 6px; }
#patch { width: 100%; }
#patch h4 {font-family: verdana,arial,helvetica,sans-serif;font-size:10pt;padding:8px;background:#369;color:#fff;margin:0;}
#patch .propset h4, #patch .binary h4 {margin:0;}
#patch pre {padding:0;line-height:1.2em;margin:0;}
#patch .diff {width:100%;background:#eee;padding: 0 0 10px 0;overflow:auto;}
#patch .propset .diff, #patch .binary .diff  {padding:10px 0;}
#patch span {display:block;padding:0 10px;}
#patch .modfile, #patch .addfile, #patch .delfile, #patch .propset, #patch .binary, #patch .copfile {border:1px solid #ccc;margin:10px 0;}
#patch ins {background:#dfd;text-decoration:none;display:block;padding:0 10px;}
#patch del {background:#fdd;text-decoration:none;display:block;padding:0 10px;}
#patch .lines, .info {color:#888;background:#fff;}
--></style>
<div id="msg">
<dl class="meta">
<dt>Revision</dt> <dd><a href="http://trac.webkit.org/projects/webkit/changeset/181457">181457</a></dd>
<dt>Author</dt> <dd>ggaren@apple.com</dd>
<dt>Date</dt> <dd>2015-03-12 15:50:11 -0700 (Thu, 12 Mar 2015)</dd>
</dl>

<h3>Log Message</h3>
<pre>Assertion failure in bmalloc::LargeObject::validateSelf on Mavericks Debug layout test bot
https://bugs.webkit.org/show_bug.cgi?id=142642

Reviewed by Michael Saboff.

The typical backtrace to this crash shows the main thread trying to
realloc a large string while a DFG compiler thread tries to
free a large vector buffer.

I believe that this is a race condition -- at least in debug builds --
since the main thread will try to validate its object's neighbors
without holding a lock, even though those neighbors might be in the
midst of changing.

In general, there may be sneaky times when it is valid to look at an
object's metadata without holding the heap lock, but it is best not to
do so unless we have a really really good reason to.

* bmalloc/Allocator.cpp:
(bmalloc::Allocator::reallocate): Take a lock before reading the metadata
for this object, since we generally require any access to shared heap
metadata to take a lock.</pre>

<h3>Modified Paths</h3>
<ul>
<li><a href="#trunkSourcebmallocChangeLog">trunk/Source/bmalloc/ChangeLog</a></li>
<li><a href="#trunkSourcebmallocbmallocAllocatorcpp">trunk/Source/bmalloc/bmalloc/Allocator.cpp</a></li>
</ul>

</div>
<div id="patch">
<h3>Diff</h3>
<a id="trunkSourcebmallocChangeLog"></a>
<div class="modfile"><h4>Modified: trunk/Source/bmalloc/ChangeLog (181456 => 181457)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/bmalloc/ChangeLog        2015-03-12 22:14:32 UTC (rev 181456)
+++ trunk/Source/bmalloc/ChangeLog        2015-03-12 22:50:11 UTC (rev 181457)
</span><span class="lines">@@ -1,3 +1,28 @@
</span><ins>+2015-03-12  Geoffrey Garen  &lt;ggaren@apple.com&gt;
+
+        Assertion failure in bmalloc::LargeObject::validateSelf on Mavericks Debug layout test bot
+        https://bugs.webkit.org/show_bug.cgi?id=142642
+
+        Reviewed by Michael Saboff.
+
+        The typical backtrace to this crash shows the main thread trying to
+        realloc a large string while a DFG compiler thread tries to
+        free a large vector buffer.
+
+        I believe that this is a race condition -- at least in debug builds --
+        since the main thread will try to validate its object's neighbors
+        without holding a lock, even though those neighbors might be in the
+        midst of changing.
+
+        In general, there may be sneaky times when it is valid to look at an
+        object's metadata without holding the heap lock, but it is best not to
+        do so unless we have a really really good reason to.
+
+        * bmalloc/Allocator.cpp:
+        (bmalloc::Allocator::reallocate): Take a lock before reading the metadata
+        for this object, since we generally require any access to shared heap
+        metadata to take a lock.
+
</ins><span class="cx"> 2015-03-10  Geoffrey Garen  &lt;ggaren@apple.com&gt;
</span><span class="cx"> 
</span><span class="cx">         bmalloc: tryFastMalloc shouldn't crash
</span></span></pre></div>
<a id="trunkSourcebmallocbmallocAllocatorcpp"></a>
<div class="modfile"><h4>Modified: trunk/Source/bmalloc/bmalloc/Allocator.cpp (181456 => 181457)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/bmalloc/bmalloc/Allocator.cpp        2015-03-12 22:14:32 UTC (rev 181456)
+++ trunk/Source/bmalloc/bmalloc/Allocator.cpp        2015-03-12 22:50:11 UTC (rev 181457)
</span><span class="lines">@@ -129,6 +129,7 @@
</span><span class="cx">         break;
</span><span class="cx">     }
</span><span class="cx">     case Large: {
</span><ins>+        std::lock_guard&lt;StaticMutex&gt; lock(PerProcess&lt;Heap&gt;::mutex());
</ins><span class="cx">         LargeObject largeObject(object);
</span><span class="cx">         oldSize = largeObject.size();
</span><span class="cx">         break;
</span></span></pre>
</div>
</div>

</body>
</html>