Skip to content
Permalink
Browse files
ASSERT under WebAutomationSession::setProcessPool() when running W3C …
…test suite a second time

https://bugs.webkit.org/show_bug.cgi?id=182991
<rdar://problem/37620578>

Reviewed by Timothy Hatcher.

Sometimes when running more than one session end-to-end with the same browser instance,
UIProcess would crash under addMessageReceiver because another WebAutomationSession was still
registered. This is hard to reproduce, but upon code inspection, the receiver management code
is somewhat problematic because it only runs when the WebAutomationSession destructor runs.
In some cases the client could retain two sessions and cause the first one to never remove itself
as the message receiver.

Instead of unregistering the session as a message receiver underneath the session's destructor,
do this whenever a new session supplants an old session since there is only one active session at a time.

* UIProcess/Automation/WebAutomationSession.cpp:
(WebKit::WebAutomationSession::~WebAutomationSession):
* UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::setAutomationSession):


Canonical link: https://commits.webkit.org/198736@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@228854 268f45cc-cd09-0410-ab3c-d52691b4dbfc
  • Loading branch information
burg committed Feb 21, 2018
1 parent 8d69f26 commit 3dd90a0748efaec405c24f58b2d4e818c3b44fe7
Showing with 27 additions and 3 deletions.
  1. +23 −0 Source/WebKit/ChangeLog
  2. +1 −3 Source/WebKit/UIProcess/Automation/WebAutomationSession.cpp
  3. +3 −0 Source/WebKit/UIProcess/WebProcessPool.cpp
@@ -1,3 +1,26 @@
2018-02-20 Brian Burg <bburg@apple.com>

ASSERT under WebAutomationSession::setProcessPool() when running W3C test suite a second time
https://bugs.webkit.org/show_bug.cgi?id=182991
<rdar://problem/37620578>

Reviewed by Timothy Hatcher.

Sometimes when running more than one session end-to-end with the same browser instance,
UIProcess would crash under addMessageReceiver because another WebAutomationSession was still
registered. This is hard to reproduce, but upon code inspection, the receiver management code
is somewhat problematic because it only runs when the WebAutomationSession destructor runs.
In some cases the client could retain two sessions and cause the first one to never remove itself
as the message receiver.

Instead of unregistering the session as a message receiver underneath the session's destructor,
do this whenever a new session supplants an old session since there is only one active session at a time.

* UIProcess/Automation/WebAutomationSession.cpp:
(WebKit::WebAutomationSession::~WebAutomationSession):
* UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::setAutomationSession):

2018-02-20 Tim Horton <timothy_horton@apple.com>

Introduce HAVE(IOSURFACE_ACCELERATOR)
@@ -71,9 +71,7 @@ WebAutomationSession::WebAutomationSession()
WebAutomationSession::~WebAutomationSession()
{
ASSERT(!m_client);

if (m_processPool)
m_processPool->removeMessageReceiver(Messages::WebAutomationSession::messageReceiverName());
ASSERT(!m_processPool);
}

void WebAutomationSession::setClient(std::unique_ptr<API::AutomationSessionClient>&& client)
@@ -1502,6 +1502,9 @@ void WebProcessPool::updateAutomationCapabilities() const

void WebProcessPool::setAutomationSession(RefPtr<WebAutomationSession>&& automationSession)
{
if (m_automationSession)
m_automationSession->setProcessPool(nullptr);

m_automationSession = WTFMove(automationSession);

#if ENABLE(REMOTE_INSPECTOR)

0 comments on commit 3dd90a0

Please sign in to comment.