none
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'::<lambda0>,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'::<lambda0>,0>::operator()()  Line 1781 + 0x16 bytes	C++
     	Lockable.exe!Concurrency::task_handle<Concurrency::_Parallel_chunk_helper<int,unsigned int,`anonymous namespace'::<lambda0>,0> >::operator()()  Line 116	C++
     	Lockable.exe!Concurrency::details::_UnrealizedChore::_InvokeBridge<Concurrency::task_handle<Concurrency::_Parallel_chunk_helper<int,unsigned int,`anonymous namespace'::<lambda0>,0> > >(Concurrency::task_handle<Concurrency::_Parallel_chunk_helper<int,unsigned int,`anonymous namespace'::<lambda0>,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() 	
    

    Another crash I've got looked like the lock had not been held (cs: not_locked) 

    	Lockable.exe!std::vector<int,std::allocator<int> >::_Orphan_range(int * _First=0x0000c5db, int * _Last=0x0000c5db)  Line 1442 + 0x5 bytes	C++
    	Lockable.exe!std::vector<int,std::allocator<int> >::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'::<lambda0>,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'::<lambda0>,0>::operator()()  Line 1833 + 0x16 bytes	C++
     	Lockable.exe!Concurrency::task_handle<Concurrency::_Parallel_chunk_helper<int,unsigned int,`anonymous namespace'::<lambda0>,0> >::operator()()  Line 116	C++
     	Lockable.exe!Concurrency::details::_UnrealizedChore::_InvokeBridge<Concurrency::task_handle<Concurrency::_Parallel_chunk_helper<int,unsigned int,`anonymous namespace'::<lambda0>,0> > >(Concurrency::task_handle<Concurrency::_Parallel_chunk_helper<int,unsigned int,`anonymous namespace'::<lambda0>,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 were 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 seemed 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!



    Thursday, January 24, 2013 3:30 AM

Answers

All replies

  • Hi,

    This is a well known issue in Visual Studio 2010. please read more details here, and here. That said, there is a concurrency performance issue with high contention on the same lock like the sample you posted. I recommend reading Best Practices in the Parallel Patterns Library.

    Have you considered concurrent_vector?

    Does the second crash occur in Visual Studio 2012?

    Thanks for your interest in PPL.


    Saturday, January 26, 2013 1:55 AM
  • Hi Mohamed,

    Thanks for providing the information regarding the issue! The other posts you linked explains the problem thoroughly.

    While I am fully aware that the pattern in the example was best to be avoided, it did exhibit the same issues under the more real world situation we have here - we have to use a bit of locking within the parallelized tasks, due to the nature that our game logic/data is not *purely* parallelizable - even though there are competitive lockings, crashes are absolutely intolerable.

    All the crashes were experienced under VS2010, while PPL under VS2012 seems to be robust so far. However, we are currently not in a position to upgrade our dev environment to VS2012 yet, so we had to switch to TBB for now.

    Regardless, it's good to know that things are getting better in VS2012, and I look forward to get my hands dirty with it soon.

    Regards,

    Lin

    Monday, January 28, 2013 3:40 PM