PPL critical_section/parallel_for crashing under visual studio 2010?

Question

I've made this simple test program, and it sometimes triggers a Debug Break or it just crashes (under Debug/Win32/VS2010SP1) - and of course, sometimes it even works. Is there anything I am doing wrong or is there a bug somewhere in PPL (VS2010)?

#include "stdafx.h"
#include <ppl.h>
#include <vector>

int _tmain(int argc, _TCHAR* argv[])
{
    std::vector<int> vi;
    Concurrency::critical_section cs;
    Concurrency::parallel_for(0, 10000, [&](int i)
    {
        Concurrency::critical_section::scoped_lock l(cs);
        vi.push_back(i);
    });
    return 0;
}

The Debug Break call stack looks like below:

msvcr100d.dll!_CrtDbgBreak() Line 85 C msvcr100d.dll!_VCrtDbgReportW(int nRptType=2, const wchar_t * szFile=0x0f45d230, int nLine=728, const wchar_t * szModule=0x00000000, const wchar_t * szFormat=0x0f45d400, char * arglist=0x7d92f7c4) Line 502 C msvcr100d.dll!_CrtDbgReportWV(int nRptType=2, const wchar_t * szFile=0x0f45d230, int nLine=728, const wchar_t * szModule=0x00000000, const wchar_t * szFormat=0x0f45d400, char * arglist=0x7d92f7c4) Line 241 + 0x1d bytes C++ msvcr100d.dll!_CrtDbgReportW(int nRptType=2, const wchar_t * szFile=0x0f45d230, int nLine=728, const wchar_t * szModule=0x00000000, const wchar_t * szFormat=0x0f45d400, ...) Line 258 + 0x1d bytes C++ msvcr100d.dll!Concurrency::details::LockQueueNode::Copy(Concurrency::details::LockQueueNode * pCopyFromNode=0x7d92f908) Line 728 + 0x27 bytes C++ msvcr100d.dll!Concurrency::critical_section::_Acquire_lock(void * _PLockingNode=0x7d92f908, bool _FHasExternalNode=true) Line 1019 C++ msvcr100d.dll!Concurrency::critical_section::scoped_lock::scoped_lock(Concurrency::critical_section & _Critical_section=locked) Line 1083 C++ Lockable.exe!anonymous namespace'::<lambda0>::operator()(int i=1418) Line 14 + 0x11 bytes C++ Lockable.exe!Concurrency::_Parallel_chunk_helper_invoke<int,unsigned int,anonymous namespace'::,0>::_Invoke(const int & _First=0, unsigned int & _Index=1418, const anonymous-namespace'::<lambda0> & _Func={...}) Line 1445 C++ Lockable.exe!Concurrency::_Parallel_chunk_helper<int,unsigned int,anonymous namespace'::,0>::operator()() Line 1781 + 0x16 bytes C++ Lockable.exe!Concurrency::task_handle,0> > >(Concurrency::task_handle,0> > * _PChore=0x7c13fba8 {_M_first=0 _M_step=1 _M_function={...} ...}) Line 3495 C++ msvcr100d.dll!Concurrency::details::_UnrealizedChore::_StructuredChoreWrapper(Concurrency::details::_UnrealizedChore * pChore=0x7c13fba8 {_M_first=0 _M_step=1 _M_function={...} ...}) Line 99 + 0xc bytes C++ msvcr100d.dll!Concurrency::details::_UnrealizedChore::_Invoke() Line 3454 + 0xc bytes C++ msvcr100d.dll!Concurrency::details::WorkItem::Invoke() Line 75 C++ msvcr100d.dll!Concurrency::details::InternalContextBase::ExecuteChoreInline(Concurrency::details::WorkItem * pWork=0x7d92fe7c) Line 1385 C++ msvcr100d.dll!Concurrency::details::InternalContextBase::Dispatch(Concurrency::DispatchState * pDispatchState=0x7d92fe9c) Line 1478 C++ msvcr100d.dll!Concurrency::details::FreeThreadProxy::Dispatch() Line 157 C++ msvcr100d.dll!Concurrency::details::ThreadProxy::ThreadProxyMain(void * lpParameter=0x2ed5b4f0) Line 162 C++ kernel32.dll!763c33aa()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!771a9ef2()
ntdll.dll!771a9ec5()

One crash I've just got looks like the lock has not been held (cs: not_locked)

Lockable.exe!std::vector >::_Orphan_range(int * _First=0x0000c5db, int * _Last=0x0000c5db) Line 1442 + 0x5 bytes C++ Lockable.exe!std::vector >::push_back(const int & _Val=4177) Line 995 C++

Lockable.exe!anonymous namespace'::<lambda0>::operator()(int i=4177) Line 16 C++ Lockable.exe!Concurrency::_Parallel_chunk_helper_invoke<int,unsigned int,anonymous namespace'::,0>::_Invoke(const int & _First=0, unsigned int & _Index=4177, const anonymous-namespace'::<lambda0> & _Func={...}) Line 1445 C++ Lockable.exe!Concurrency::_Parallel_chunk_helper<int,unsigned int,anonymous namespace'::,0>::operator()() Line 1833 + 0x16 bytes C++ Lockable.exe!Concurrency::task_handle,0> > >(Concurrency::task_handle,0> > * _PChore=0x7cbffc24 {_M_first=0 _M_step=1 _M_function={...} ...}) Line 3495 C++ msvcr100d.dll!Concurrency::details::_UnrealizedChore::_StructuredChoreWrapper(Concurrency::details::_UnrealizedChore * pChore=0x7cbffc24 {_M_first=0 _M_step=1 _M_function={...} ...}) Line 99 + 0xc bytes C++ msvcr100d.dll!Concurrency::details::_UnrealizedChore::_Invoke() Line 3454 + 0xc bytes C++ msvcr100d.dll!Concurrency::details::WorkItem::Invoke() Line 75 C++ msvcr100d.dll!Concurrency::details::InternalContextBase::ExecuteChoreInline(Concurrency::details::WorkItem * pWork=0x7bc0fab4) Line 1385 C++ msvcr100d.dll!Concurrency::details::InternalContextBase::Dispatch(Concurrency::DispatchState * pDispatchState=0x7bc0fad4) Line 1478 C++ msvcr100d.dll!Concurrency::details::FreeThreadProxy::Dispatch() Line 157 C++ msvcr100d.dll!Concurrency::details::ThreadProxy::ThreadProxyMain(void * lpParameter=0x2dcf6200) Line 162 C++ kernel32.dll!763c33aa()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!771a9ef2()
ntdll.dll!771a9ec5()

And there could be other random access violations even inside the PPL internal implementation, that I guess you could be able to reproduce. (hopefully)

I ran the same program under Visual Studio 2012 Express for Desktop, and everything seems to be working properly after many test runs.

I'm wondering that if PPL under VS2010 is buggy to be used in a production environment?

Thanks for any inputs!

Answer 1

So finally, after posting a question on Microsoft Connect (or Social?), the issue has been explained thoroughly.

http://social.msdn.microsoft.com/Forums/en-US/parallelcppnative/thread/9601a2d0-b1ef-4d81-8743-73c3965a7b63

http://social.msdn.microsoft.com/Forums/eu/parallelcppnative/thread/38d2e8c8-e863-4da0-a45a-9776ab27feed

Answer 2

In my opinion, you should wait at the end of program. The routine parallel_for has created thread(s) for concurrent execution, and would run on their own. But, the main is exiting, which would cause all running threads to cease (or make them invalid).

Try putting some blocking call (as simple as user-input), and see if it works.