127820 2014-01-28 18:18:12 -0800 API tests on Windows fail after r162774 (Debug) 2016-03-22 14:06:09 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) PC Windows 7 RESOLVED WORKSFORME P2 Normal --- 1 roger_fong webkit-unassigned achristensen andersca bfulgham drake127 roger_fong oldest_to_newest 973242 0 roger_fong 2014-01-28 18:18:12 -0800 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. 973243 1 roger_fong 2014-01-28 18:19:32 -0800 perhaps just --gtest-list-tests? 973444 2 roger_fong 2014-01-29 12:28:43 -0800 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; } 973449 3 roger_fong 2014-01-29 12:56:47 -0800 > #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 973450 4 roger_fong 2014-01-29 13:06:46 -0800 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 992299 5 drake127 2014-03-19 15:45:22 -0700 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. :/ 1177117 6 bfulgham 2016-03-22 14:06:09 -0700 This doesn't seem to happen anymore. Looks like this was resolved in one of the VS updates.