Bug 127820 – API tests on Windows fail after r162774 (Debug)

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Tools / Tests

[Roger Fong]

Tests fail trying to build the list of tests to run.
It only fails in Debug mode.

Looking at the changeset, it looks like it has something to do with using CHECK_HASHTABLE_ITERATORS.
-#ifndef NDEBUG
-// Required for CHECK_HASHTABLE_ITERATORS.
-#include <wtf/OwnPtr.h>
-#include <wtf/PassOwnPtr.h>
-#endif

It looks like the replacing of those two headers with std headers caused some problems.
Once I figure out which arguments I need to pass into TestWebKitAPI.exe to get that step to run in the debugger i'll post a stack trace.

[Roger Fong]

perhaps just --gtest-list-tests?

[Roger Fong]

First-chance exception at 0x76D12EEC in TestWebKitAPI.exe: Microsoft C++ exception: Concurrency::scheduler_resource_allocation_error at memory location 0x0018FB90.
Unhandled exception at 0x76D12EEC in TestWebKitAPI.exe: Microsoft C++ exception: Concurrency::scheduler_resource_allocation_error at memory location 0x0018FB90.

In this code:

#if CHECK_HASHTABLE_ITERATORS

    template<typename Key, typename Value, typename Extractor, typename HashFunctions, typename Traits, typename KeyTraits>
    void HashTable<Key, Value, Extractor, HashFunctions, Traits, KeyTraits>::invalidateIterators()
    {
        std::lock_guard<std::mutex> lock(*m_mutex);
        const_iterator* next;
        for (const_iterator* p = m_iterators; p; p = next) {  <----HERE
            next = p->m_next;
            p->m_table = 0;
            p->m_next = 0;
            p->m_previous = 0;
        }
        m_iterators = 0;
    }

[Roger Fong]

> #if CHECK_HASHTABLE_ITERATORS
> 
>     template<typename Key, typename Value, typename Extractor, typename HashFunctions, typename Traits, typename KeyTraits>
>     void HashTable<Key, Value, Extractor, HashFunctions, Traits, KeyTraits>::invalidateIterators()
>     {
>         std::lock_guard<std::mutex> lock(*m_mutex); <----HERE

Correction it's on this line

[Roger Fong]

Looks like we got something funky going on with the VS2013 headers

inline int _Mtx_lockX(_Mtx_t *_Mtx)
	{	// throw exception on failure
	return (_Check_C_return(_Mtx_lock(_Mtx)));
	}

in xthread.h is throwing the exception

[Emanuel Komínek]

I am not related to WebKit but suffer from same bug in our software. Has somebody been able to reproduce it?

It is likely a bug in implementation of std::mutex by MS (both VS 2012 and VS 2013 runtime) but I got my hands only on minidumps which were inconclusive.

So far, we observed this crash only on 32-bit Windows and our failing function was RegisterWaitForSingleObject and call stack is as follows:

_CxxThrowException+0x57 [f:\dd\vctools\crt_bld\self_x86\crt\prebuild\eh\throw.cpp @ 152]
Concurrency::details::SchedulerBase::SchedulerBase+0x23b [f:\dd\vctools\crt_bld\self_x86\crt\src\schedulerbase.cpp @ 146]
Concurrency::details::ThreadScheduler::ThreadScheduler+0x18 [f:\dd\vctools\crt_bld\self_x86\crt\src\threadscheduler.cpp @ 26]
Concurrency::details::ThreadScheduler::Create+0x2d [f:\dd\vctools\crt_bld\self_x86\crt\src\threadscheduler.cpp @ 35]
Concurrency::details::SchedulerBase::CreateWithoutInitializing+0x18 [f:\dd\vctools\crt_bld\self_x86\crt\src\schedulerbase.cpp @ 276]
Concurrency::details::SchedulerBase::GetDefaultScheduler+0x5c [f:\dd\vctools\crt_bld\self_x86\crt\src\schedulerbase.cpp @ 650]
Concurrency::details::SchedulerBase::CreateContextFromDefaultScheduler+0x7 [f:\dd\vctools\crt_bld\self_x86\crt\src\schedulerbase.cpp @ 567]
Concurrency::details::LockQueueNode::LockQueueNode+0x27 [f:\dd\vctools\crt_bld\self_x86\crt\src\rtlocks.cpp @ 617]
Concurrency::critical_section::lock+0x13 [f:\dd\vctools\crt_bld\self_x86\crt\src\rtlocks.cpp @ 1022]
mtx_do_lock+0x74 [f:\dd\vctools\crt_bld\self_x86\crt\src\thr\mutex.c @ 65]
_Mtx_lock+0xd [f:\dd\vctools\crt_bld\self_x86\crt\src\thr\mutex.c @ 144]

The problem is, I never saw what was happening in the RegisterWaitForSingleObject call so I cannot say what exactly went wrong. :/

[Brent Fulgham]

This doesn't seem to happen anymore. Looks like this was resolved in one of the VS updates.