[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