[Webkit-unassigned] [Bug 44137] Crash beneath WTF::ThreadSpecificThreadExit (jump-to-null) when running websocket/tests/workers/close-in-shared-worker.html

[bugzilla-daemon at webkit.org]

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


David Levin <levin at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |levin at chromium.org




--- Comment #3 from David Levin <levin at chromium.org>  2010-11-30 14:42:49 PST ---
Something went wrong with the value stored in tls.

Here's the code that crashes:

void ThreadSpecificThreadExit()
{
    for (long i = 0; i < tlsKeyCount(); i++) {
        // The layout of ThreadSpecific<T>::Data does not depend on T. So we are safe to do the static cast to ThreadSpecific<int> in order to access its data member.
        ThreadSpecific<int>::Data* data = static_cast<ThreadSpecific<int>::Data*>(TlsGetValue(tlsKeys()[i]));
        if (data)
            data->destructor(data);
    }

It crashed calling destructor here:  "data->destructor(data);"

It was able to access data->destructor, but the value at data->destructor was 0 (which is where it called and crashed).

So either
1. The tls value was over written in some way. (-- Some other code reused the same slot or the tls data structure was corrupted, etc. This seems really unlikely).
2. The data structure was overwritten.
3. The data structure was freed and something new was allocated at that place which happened to have 0 there.

My gut reaction is "3".

Also it is interesting to note that there is a worker running and doing a sync xhr on thread #12 when this happened. (Of course, thread 17 could still be a former web worker thread that was exiting.)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.