[Webkit-unassigned] [Bug 88094] Web Inspector: Add a WebInspectorServer on Linux using the GSocket API for the GTK port
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Sep 17 01:37:57 PDT 2012
https://bugs.webkit.org/show_bug.cgi?id=88094
--- Comment #30 from Jocelyn Turcotte <jocelyn.turcotte at nokia.com> 2012-09-17 01:38:23 PST ---
(From update of attachment 163880)
View in context: https://bugs.webkit.org/attachment.cgi?id=163880&action=review
>>>> Source/WebKit2/UIProcess/InspectorServer/WebSocketServerConnection.cpp:130
>>>> + return;
>>>
>>> Can you elaborate on this? If in any case didCloseWebSocketServerConnection isn't run, this would prevent the server from accepting a new connection if the previous connection wasn't cleaned-up properly.
>>
>> I think if m_socket is 0 didCloseWebSocketServerConnection has been already called, I will attach call stack to show why double deletion happens.
>
> The call stack:
> 0 __GI_raise raise.c 64 0x7ffff283f445
> 1 __GI_abort abort.c 91 0x7ffff2842bab
> 2 __libc_message libc_fatal.c 201 0x7ffff287ce2e
> 3 malloc_printerr malloc.c 5007 0x7ffff2887626
> 4 WebKit::WebSocketServerConnection::~WebSocketServerConnection WebSocketServerConnection.cpp 60 0x7ffff43e590e
> 5 WTF::deleteOwnedPtr<WebKit::WebSocketServerConnection> OwnPtrCommon.h 56 0x7ffff43e57ec
> 6 WTF::OwnPtr<WebKit::WebSocketServerConnection>::~OwnPtr OwnPtr.h 55 0x7ffff43e5783
> 7 WTF::VectorDestructor<true, WTF::OwnPtr<WebKit::WebSocketServerConnection> >::destruct Vector.h 59 0x7ffff43e563f
> 8 WTF::VectorTypeOperations<WTF::OwnPtr<WebKit::WebSocketServerConnection> >::destruct Vector.h 221 0x7ffff43e5181
> 9 WTF::Deque<WTF::OwnPtr<WebKit::WebSocketServerConnection>, 0ul>::remove Deque.h 516 0x7ffff43e4fbd
> 10 WTF::Deque<WTF::OwnPtr<WebKit::WebSocketServerConnection>, 0ul>::remove Deque.h 496 0x7ffff43e45d1
> 11 WebKit::WebSocketServer::didCloseWebSocketServerConnection WebSocketServer.cpp 95 0x7ffff43e4267
> 12 WebKit::WebSocketServerConnection::didCloseSocketStream WebSocketServerConnection.cpp 137 0x7ffff43e5ef1
> 13 WebCore::SocketStreamHandle::platformClose SocketStreamHandleSoup.cpp 205 0x7ffff4e5477c
> 14 WebCore::SocketStreamHandleBase::disconnect SocketStreamHandleBase.cpp 98 0x7ffff4e48c82
> 15 WebCore::SocketStreamHandleBase::close SocketStreamHandleBase.cpp 91 0x7ffff4e48c44
> 16 WebCore::SocketStreamHandle::readBytes SocketStreamHandleSoup.cpp 140 0x7ffff4e54327
> 17 WebCore::readReadyCallback SocketStreamHandleSoup.cpp 274 0x7ffff4e54bf3
> 18 async_ready_callback_wrapper ginputstream.c 529 0x7ffff33b1775
> 19 g_simple_async_result_complete gsimpleasyncresult.c 767 0x7ffff33c68dd
> 20 complete_in_idle_cb gsimpleasyncresult.c 779 0x7ffff33c6a0c
> ... <More>
>
> SocketStreamHandle instance gets deleted as a part of WebSocketServerConnection instance. if I protect SocketStreamHandle before close() call the issue seems to be fixed,
> however there another crush might occur. Will investigate it further and fix after my 2 weeks trip.
>
>
> void SocketStreamHandle::readBytes(signed long bytesRead, GError* error)
> {
> if (error) {
> m_client->didFailSocketStream(this, SocketStreamError(error->code, error->message));
> return;
> }
>
> + RefPtr<SocketStreamHandle> protect(this);
> if (!bytesRead) {
> close();
> return;
> }
>
> // The client can close the handle, potentially removing the last reference.
> - RefPtr<SocketStreamHandle> protect(this);
To me this confirms that WebSocketServer::didCloseWebSocketServerConnection has something to clean up, thus that preventing this call would make it impossible to re-inspect a page after closing a previous browser window.
I remember that the order of destruction was pretty tight around there for Qt as well, and things might have to be adjusted a bit for GTK. Feel free to ping me on IRC if you see the need.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list