[Webkit-unassigned] [Bug 185073] REGRESSION(iOS 11.3): Crashes in TimerBase::~TimerBase() in Tencent x5gamehelper

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=185073

--- Comment #4 from Chris Dumez <cdumez at apple.com> ---
(In reply to Alexey Proskuryakov from comment #3)
> Actually, thread 0 must be the wrong thread here. I'm guessing that
> WebSocketChannel got refactored without considering legacy WebKit on iOS.e
Alexey is right that it seems unexpected for code such as EventTarget::dispatchEvent() to run on thread 0 in WebKitLegacy. I would have expected such code to run on the Web thread.

As we can see from the trace, we're already on thread 0 from SocketStreamHandleImpl::readStreamCallback(unsigned long).

This callback is scheduled in SocketStreamHandleImpl::scheduleStreams() like so:
CFReadStreamSetClient(m_readStream.get(), static_cast<CFOptionFlags>(-1), readStreamCallback, &clientContext);
CFReadStreamScheduleWithRunLoop(m_readStream.get(), CFRunLoopGetCurrent(), kCFRunLoopCommonModes);

It is using CFRunLoopGetCurrent() so this is only safe if SocketStreamHandleImpl::scheduleStreams() gets called on the Web thread. It is called from the SocketStreamHandleImpl() constructor, which is called from SocketProvider::createSocketStreamHandle().
This is called from WebSocketChannel::connect(), which I would expect to run on the WebThread given what it does. It is called from WebSocket::connect() which is Web-exposed and should therefore be called on the WebThread.

I do not see anything obviously wrong with the code yet. I am also not aware of any recent refactoring in this part of the code. I'll investigate furthere

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180430/44474170/attachment.html>