Title: [163661] trunk/Source/_javascript_Core
Revision
163661
Author
mark....@apple.com
Date
2014-02-07 16:24:13 -0800 (Fri, 07 Feb 2014)

Log Message

Fix bug in stack limit adjustments in JSLock.
<https://webkit.org/b/128406>

Reviewed by Geoffrey Garen.

1. JSLock::unlock() was only clearing the VM::stackPointerAtEntry when
   m_vm->stackPointerAtVMEntry == entryStackPointer. FYI,
   entryStackPointer is a field in JSLock.

   When DropAllLocks::~DropAllLocks() will call JSLock::grabAllLocks()
   to relock the JSLock, JSLock::grabAllLocks() will set a new
   entryStackPointer value. Thereafter, DropAllLocks::~DropAllLocks() will
   restore the saved VM::stackPointerAtEntry, which will now defer from
   the JSLock's entryStackPointer value.

   It turns out that when m_vm->stackPointerAtVMEntry was initialized,
   it was set to whatever value entryStackPointer is set to. At no time
   do we ever expect the 2 values to differ. The only time it differs is
   when this bug manifests.

   The fix is to remove the entryStackPointer field in JSLock and its uses
   altogether.

2. DropAllLocks was unconditionally clearing VM::stackPointerAtEntry in
   its constructor instead of letting JSLock::unlock() do the clearing.

   However, DropAllLocks will not actually drop locks if it isn't required
   to (e.g. when alwaysDropLocks is DontAlwaysDropLocks), and when we've
   already drop locks once (i.e. JSLock::m_lockDropDepth is not 0).

   We should not have cleared VM::stackPointerAtEntry here if we don't
   actually drop the locks.

* runtime/JSLock.cpp:
(JSC::JSLock::unlock):
(JSC::JSLock::DropAllLocks::DropAllLocks):

Modified Paths

Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (163660 => 163661)


--- trunk/Source/_javascript_Core/ChangeLog	2014-02-08 00:19:49 UTC (rev 163660)
+++ trunk/Source/_javascript_Core/ChangeLog	2014-02-08 00:24:13 UTC (rev 163661)
@@ -1,3 +1,42 @@
+2014-02-07  Mark Lam  <mark....@apple.com>
+
+        Fix bug in stack limit adjustments in JSLock.
+        <https://webkit.org/b/128406>
+
+        Reviewed by Geoffrey Garen.
+
+        1. JSLock::unlock() was only clearing the VM::stackPointerAtEntry when
+           m_vm->stackPointerAtVMEntry == entryStackPointer. FYI,
+           entryStackPointer is a field in JSLock.
+
+           When DropAllLocks::~DropAllLocks() will call JSLock::grabAllLocks()
+           to relock the JSLock, JSLock::grabAllLocks() will set a new
+           entryStackPointer value. Thereafter, DropAllLocks::~DropAllLocks() will
+           restore the saved VM::stackPointerAtEntry, which will now defer from
+           the JSLock's entryStackPointer value.
+
+           It turns out that when m_vm->stackPointerAtVMEntry was initialized,
+           it was set to whatever value entryStackPointer is set to. At no time
+           do we ever expect the 2 values to differ. The only time it differs is
+           when this bug manifests.
+
+           The fix is to remove the entryStackPointer field in JSLock and its uses
+           altogether.
+
+        2. DropAllLocks was unconditionally clearing VM::stackPointerAtEntry in
+           its constructor instead of letting JSLock::unlock() do the clearing.
+
+           However, DropAllLocks will not actually drop locks if it isn't required
+           to (e.g. when alwaysDropLocks is DontAlwaysDropLocks), and when we've
+           already drop locks once (i.e. JSLock::m_lockDropDepth is not 0).
+
+           We should not have cleared VM::stackPointerAtEntry here if we don't
+           actually drop the locks.
+
+        * runtime/JSLock.cpp:
+        (JSC::JSLock::unlock):
+        (JSC::JSLock::DropAllLocks::DropAllLocks):
+
 2014-02-07  Joseph Pecoraro  <pecor...@apple.com>
 
         [iOS] Eliminate race between XPC connection queue and Notification queue

Modified: trunk/Source/_javascript_Core/runtime/JSLock.cpp (163660 => 163661)


--- trunk/Source/_javascript_Core/runtime/JSLock.cpp	2014-02-08 00:19:49 UTC (rev 163660)
+++ trunk/Source/_javascript_Core/runtime/JSLock.cpp	2014-02-08 00:24:13 UTC (rev 163661)
@@ -142,7 +142,7 @@
     m_lockCount--;
 
     if (!m_lockCount) {
-        if (m_vm && m_vm->stackPointerAtVMEntry == entryStackPointer) {
+        if (m_vm) {
             m_vm->stackPointerAtVMEntry = nullptr;
             m_vm->updateStackLimitWithReservedZoneSize(wtfThreadData().savedReservedZoneSize());
         }
@@ -312,8 +312,6 @@
     threadData.setSavedLastStackTop(m_vm->lastStackTop());
     threadData.setSavedReservedZoneSize(m_vm->reservedZoneSize());
 
-    m_vm->stackPointerAtVMEntry = nullptr;
-
     if (alwaysDropLocks)
         m_lockCount = m_vm->apiLock().dropAllLocksUnconditionally(spinLock);
     else
@@ -337,8 +335,6 @@
     threadData.setSavedLastStackTop(m_vm->lastStackTop());
     threadData.setSavedReservedZoneSize(m_vm->reservedZoneSize());
 
-    m_vm->stackPointerAtVMEntry = nullptr;
-
     if (alwaysDropLocks)
         m_lockCount = m_vm->apiLock().dropAllLocksUnconditionally(spinLock);
     else
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to