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.
perhaps just --gtest-list-tests?
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; }
> #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
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
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. :/
This doesn't seem to happen anymore. Looks like this was resolved in one of the VS updates.