Bug 165962 - REGRESSION: HipChat and Mail sometimes hang beneath JSC::Heap::lastChanceToFinalize()
Summary: REGRESSION: HipChat and Mail sometimes hang beneath JSC::Heap::lastChanceToFi...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Michael Saboff
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2016-12-16 11:07 PST by Michael Saboff
Modified: 2017-01-11 16:01 PST (History)
6 users (show)

See Also:


Attachments
Patch (5.58 KB, patch)
2016-12-16 11:24 PST, Michael Saboff
no flags Details | Formatted Diff | Diff
Addressed Phil's comments and fixed m_condition ASSERTs (5.93 KB, patch)
2016-12-16 12:05 PST, Michael Saboff
fpizlo: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Saboff 2016-12-16 11:07:22 PST
There is an inherent race when waiting on the condition variable and the timeout fires.  The waitFor() can timeout just before getting a notification from another thread.

AutomaticThread::start() uses a condition variable to wait for work from another thread.  The other thread waits for the machine thread to respond to the notification, but instead it goes to sleep since it doesn't see the notification.
Comment 1 Michael Saboff 2016-12-16 11:24:10 PST
Created attachment 297335 [details]
Patch
Comment 2 Filip Pizlo 2016-12-16 11:43:30 PST
Comment on attachment 297335 [details]
Patch

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

> Source/WTF/wtf/AutomaticThread.cpp:50
> +    m_condition.notifyOne();

This is sort of wrong since it makes notifyOne mean notifyTwo.

Programs that use notifyOne often rely on the bounded nature of the wake-up.  I think that one solution is to simply move this call to the bottom of the method: only m_condition.notifyOne() if we did not find any threads to wake up ourselves.

> Source/WTF/wtf/AutomaticThread.cpp:212
> +                        if (!awokenByNotify && m_isWaiting) {
> +                            m_isWaiting = false;

Do we still need awokenByNotify?
Comment 3 Michael Saboff 2016-12-16 11:47:20 PST
(In reply to comment #2)
> Comment on attachment 297335 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=297335&action=review
> 
> > Source/WTF/wtf/AutomaticThread.cpp:50
> > +    m_condition.notifyOne();
> 
> This is sort of wrong since it makes notifyOne mean notifyTwo.
> 
> Programs that use notifyOne often rely on the bounded nature of the wake-up.
> I think that one solution is to simply move this call to the bottom of the
> method: only m_condition.notifyOne() if we did not find any threads to wake
> up ourselves.

That makes sense.  I'll make that change.

> > Source/WTF/wtf/AutomaticThread.cpp:212
> > +                        if (!awokenByNotify && m_isWaiting) {
> > +                            m_isWaiting = false;
> 
> Do we still need awokenByNotify?

No.  I'll remove it.
Comment 4 Michael Saboff 2016-12-16 12:05:40 PST
Created attachment 297339 [details]
Addressed Phil's comments and fixed m_condition ASSERTs
Comment 5 Michael Saboff 2016-12-16 14:26:46 PST
Committed r209938: <http://trac.webkit.org/changeset/209938>
Comment 6 Geoffrey Garen 2017-01-11 16:01:01 PST
<rdar://problem/29229439>