Bug 128641 - DelayedReleaseScope in MarkedAllocator::tryAllocateHelper is racy
Summary: DelayedReleaseScope in MarkedAllocator::tryAllocateHelper is racy
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mark Hahnenberg
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-11 17:52 PST by Mark Hahnenberg
Modified: 2014-02-12 20:19 PST (History)
3 users (show)

See Also:


Attachments
Patch (4.01 KB, patch)
2014-02-11 20:57 PST, Mark Hahnenberg
no flags Details | Formatted Diff | Diff
Patch (4.10 KB, patch)
2014-02-11 22:24 PST, Mark Hahnenberg
no flags Details | Formatted Diff | Diff
Patch (3.65 KB, patch)
2014-02-11 22:26 PST, Mark Hahnenberg
no flags Details | Formatted Diff | Diff
Patch (4.53 KB, patch)
2014-02-12 07:05 PST, Mark Hahnenberg
no flags Details | Formatted Diff | Diff
Patch (5.50 KB, patch)
2014-02-12 12:50 PST, Mark Hahnenberg
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Hahnenberg 2014-02-11 17:52:14 PST
It causes the VM to drop the lock in the middle of adding a new block to the allocator, so another thread could come in and add a block before we're done.
Comment 1 Mark Hahnenberg 2014-02-11 20:45:42 PST
(In reply to comment #0)
> It causes the VM to drop the lock in the middle of adding a new block to the allocator, so another thread could come in and add a block before we're done.

Actually, it was the DelayedReleaseScope in tryAllocateHelper that was wrong.
Comment 2 Mark Hahnenberg 2014-02-11 20:57:32 PST
Created attachment 223936 [details]
Patch
Comment 3 Mark Hahnenberg 2014-02-11 21:05:16 PST
Comment on attachment 223936 [details]
Patch

This still has issues.
Comment 4 Mark Hahnenberg 2014-02-11 22:24:35 PST
Created attachment 223941 [details]
Patch
Comment 5 Mark Hahnenberg 2014-02-11 22:26:09 PST
Created attachment 223942 [details]
Patch
Comment 6 Mark Hahnenberg 2014-02-12 07:05:26 PST
Created attachment 223969 [details]
Patch
Comment 7 Mark Lam 2014-02-12 10:08:40 PST
Comment on attachment 223969 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=223969&action=review

> Source/JavaScriptCore/heap/MarkedAllocator.cpp:109
> +    void* head = tryPopFreeList(bytes);
>      ASSERT(head);

According to tryPopFreeList() below, it can return a 0.  So, is this assertion still valid?
Comment 8 Mark Hahnenberg 2014-02-12 10:09:55 PST
(In reply to comment #7)
> (From update of attachment 223969 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=223969&action=review
> 
> > Source/JavaScriptCore/heap/MarkedAllocator.cpp:109
> > +    void* head = tryPopFreeList(bytes);
> >      ASSERT(head);
> 
> According to tryPopFreeList() below, it can return a 0.  So, is this assertion still valid?

Yes. We will loop around the while loop until m_freeList.head is not null. If m_freeList.head is not null then tryPopFreeList *must* succeed.
Comment 9 Oliver Hunt 2014-02-12 10:42:40 PST
Comment on attachment 223969 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=223969&action=review

> Source/JavaScriptCore/heap/MarkedAllocator.cpp:116
> +    ASSERT(m_currentBlock);

RELEASE_ASSERT?

> Source/JavaScriptCore/heap/MarkedAllocator.cpp:127
>      ASSERT(!m_heap->isBusy());

Can we RELEASE_ASSERT here without hurting perf?
Comment 10 Mark Hahnenberg 2014-02-12 12:50:57 PST
Created attachment 223996 [details]
Patch
Comment 11 Michael Saboff 2014-02-12 15:40:01 PST
Comment on attachment 223996 [details]
Patch

r=me
Comment 12 WebKit Commit Bot 2014-02-12 20:19:38 PST
Comment on attachment 223996 [details]
Patch

Clearing flags on attachment: 223996

Committed r164009: <http://trac.webkit.org/changeset/164009>
Comment 13 WebKit Commit Bot 2014-02-12 20:19:42 PST
All reviewed patches have been landed.  Closing bug.