D
DeepakCoder
Guest
I have a C++ application which has multiple threads which runs the code in different dlls. These two threads create and manipulate different physical files using std:fstream.
But after i compiled the same old project with visual studio 2017, there is a strange dead lock that is happening on the ofstream object creation. Here is the stack trace taken from windbg
13 Id: 15c4.c18 Suspend: 0 Teb: 00007ff7`2be60000 Unfrozen
# Child-SP RetAddr Call Site
00 0000007d`b890f578 00007fff`5424de39 ntdll!NtWaitForSingleObject+0xa
01 0000007d`b890f580 00007fff`5424b7e4 ntdll!RtlpWaitOnCriticalSection+0xe1
02 0000007d`b890f650 00007fff`4c1161e0 ntdll!RtlpEnterCriticalSectionContended+0xa4
03 0000007d`b890f690 00007fff`4c1160d5 ucrtbase!__acrt_stdio_allocate_stream+0x130
04 0000007d`b890f6d0 00007fff`4c112578 ucrtbase!__acrt_stdio_allocate_stream+0x25
05 0000007d`b890f700 00007fff`4c331660 ucrtbase!fsopen+0x58
06 (Inline Function) --------`-------- msvcp140!std::_Xfsopen+0x14 [d:\agent\_work\2\s\src\vctools\crt\crtw32\stdcpp\fiopen.cpp @ 17]
07 0000007d`b890f750 00007fff`449bb373 msvcp140!std::_Xfiopen<char>+0xe0 [d:\agent\_work\2\s\src\vctools\crt\crtw32\stdcpp\fiopen.cpp @ 90]
08 0000007d`b890f780 00007fff`449bc86c jsonout_plugin!genint::lib::rotatable_ofstream::do_open+0x83
09 0000007d`b890f800 00007fff`449bd99b jsonout_plugin!genint::lib::rotatable_ofstream::rotate+0xb7c
0a 0000007d`b890fae0 00007fff`449bd464 jsonout_plugin!genint::lib::rotatable_ofstream::update+0x1db
0b 0000007d`b890fb50 00007fff`4c331ed3 jsonout_plugin!genint::lib::rotatable_ofstream:bservable_filebuf::sync+0x64
0c (Inline Function) --------`-------- msvcp140!std::basic_streambuf<char,std::char_traits<char> >:ubsync+0xd [d:\agent\_work\2\s\src\vctools\crt\crtw32\stdhpp\streambuf @ 143]
0d 0000007d`b890fb80 00007fff`449a65eb msvcp140!std::basic_ostream<char,std::char_traits<char> >::flush+0x53 [d:\agent\_work\2\s\src\vctools\crt\crtw32\stdhpp\ostream @ 591]
0e 0000007d`b890fc00 00007fff`449a1c00 jsonout_plugin!std::endl<char,std::char_traits<char> >+0x43
0f 0000007d`b890fc30 00007ff7`2c93dbc5 jsonout_plugin!genint::jsonout_plugin::json_sink_node::execute+0x13c
10 0000007d`b890fd50 00007ff7`2c90f10c genintd!genint:ipeline::node_lifecycle_impl<1>::execute+0x2d
11 0000007d`b890fd80 00007ff7`2c9139eb genintd!genint:ipeline::node::thread_run+0x100
12 0000007d`b890fe80 00007ff7`2c914a36 genintd!boost::_bi::bind_t<void,std::mem_fun_t<void,genint:ipeline::node>,boost::_bi::list1<boost::_bi::value<genint:ipeline::node * __ptr64> > >:perator()+0x23
13 0000007d`b890fec0 00007ff7`2c95ebc3 genintd!boost::detail::thread_data<boost::_bi::bind_t<void,std::mem_fun_t<void,genint:ipeline::node>,boost::_bi::list1<boost::_bi::value<genint:ipeline::node * __ptr64> > > >::run+0x1a
14 0000007d`b890fef0 00007fff`4c12cd70 genintd!boost::system::system_category+0x53
15 0000007d`b890ff30 00007fff`520e13d2 ucrtbase!o__realloc_base+0x60
16 0000007d`b890ff60 00007fff`542254f4 kernel32!BaseThreadInitThunk+0x22
17 0000007d`b890ff90 00000000`00000000 ntdll!RtlUserThreadStart+0x34
do_open() is my function where i call this function
std::filebuf open().
ANybody has any idea why this kind of critical section deadlock can happen just while creating a filebuf
Same happens for this code as well..
std::fstream open("filename", std::ios::binary | std::ios::in | std::ios:ut);
# Child-SP RetAddr Call Site
00 000000d4`02bfdc78 00007ffb`8a6057ff ntdll!NtWaitForAlertByThreadId+0x14
01 000000d4`02bfdc80 00007ffb`8a605706 ntdll!RtlpWaitOnAddressWithTimeout+0x43
02 000000d4`02bfdcb0 00007ffb`8a605597 ntdll!RtlpWaitOnAddress+0xb2
03 000000d4`02bfdd20 00007ffb`8a5c4bf4 ntdll!RtlpWaitOnCriticalSection+0xdb
04 000000d4`02bfddf0 00007ffb`8a5c4b20 ntdll!RtlpEnterCriticalSectionContended+0xcc
05 000000d4`02bfde20 00007ffb`875061e0 ntdll!RtlEnterCriticalSection+0x40
06 000000d4`02bfde50 00007ffb`875060d5 ucrtbase!find_or_allocate_unused_stream_nolock+0xc4
07 000000d4`02bfde90 00007ffb`87502578 ucrtbase!__acrt_stdio_allocate_stream+0x25
08 000000d4`02bfdec0 00007ffb`7d3c1660 ucrtbase!common_fsopen<char>+0x4c
*** WARNING: Unable to verify checksum for ws-plugin.dll
09 (Inline Function) --------`-------- msvcp140!std::_Xfsopen+0x14 [d:\agent\_work\3\s\src\vctools\crt\crtw32\stdcpp\fiopen.cpp @ 17]
0a 000000d4`02bfdf10 00007ffb`61c4fc6f msvcp140!std::_Xfiopen<char>+0xe0 [d:\agent\_work\3\s\src\vctools\crt\crtw32\stdcpp\fiopen.cpp @ 90]
0b 000000d4`02bfdf40 00007ffb`61c4fd18 ws_plugin!std::basic_filebuf<char,std::char_traits<char> >:pen+0x43
0c 000000d4`02bfdfa0 00007ffb`61c4e1ed ws_plugin!std::basic_fstream<char,std::char_traits<char> >:pen+0x38
0d 000000d4`02bfdfd0 00007ffb`61c4e0fb ws_plugin!genint:ersistence::handle::do_open+0xe1
Has someone come across such problem ?
Continue reading...
But after i compiled the same old project with visual studio 2017, there is a strange dead lock that is happening on the ofstream object creation. Here is the stack trace taken from windbg
13 Id: 15c4.c18 Suspend: 0 Teb: 00007ff7`2be60000 Unfrozen
# Child-SP RetAddr Call Site
00 0000007d`b890f578 00007fff`5424de39 ntdll!NtWaitForSingleObject+0xa
01 0000007d`b890f580 00007fff`5424b7e4 ntdll!RtlpWaitOnCriticalSection+0xe1
02 0000007d`b890f650 00007fff`4c1161e0 ntdll!RtlpEnterCriticalSectionContended+0xa4
03 0000007d`b890f690 00007fff`4c1160d5 ucrtbase!__acrt_stdio_allocate_stream+0x130
04 0000007d`b890f6d0 00007fff`4c112578 ucrtbase!__acrt_stdio_allocate_stream+0x25
05 0000007d`b890f700 00007fff`4c331660 ucrtbase!fsopen+0x58
06 (Inline Function) --------`-------- msvcp140!std::_Xfsopen+0x14 [d:\agent\_work\2\s\src\vctools\crt\crtw32\stdcpp\fiopen.cpp @ 17]
07 0000007d`b890f750 00007fff`449bb373 msvcp140!std::_Xfiopen<char>+0xe0 [d:\agent\_work\2\s\src\vctools\crt\crtw32\stdcpp\fiopen.cpp @ 90]
08 0000007d`b890f780 00007fff`449bc86c jsonout_plugin!genint::lib::rotatable_ofstream::do_open+0x83
09 0000007d`b890f800 00007fff`449bd99b jsonout_plugin!genint::lib::rotatable_ofstream::rotate+0xb7c
0a 0000007d`b890fae0 00007fff`449bd464 jsonout_plugin!genint::lib::rotatable_ofstream::update+0x1db
0b 0000007d`b890fb50 00007fff`4c331ed3 jsonout_plugin!genint::lib::rotatable_ofstream:bservable_filebuf::sync+0x64
0c (Inline Function) --------`-------- msvcp140!std::basic_streambuf<char,std::char_traits<char> >:ubsync+0xd [d:\agent\_work\2\s\src\vctools\crt\crtw32\stdhpp\streambuf @ 143]
0d 0000007d`b890fb80 00007fff`449a65eb msvcp140!std::basic_ostream<char,std::char_traits<char> >::flush+0x53 [d:\agent\_work\2\s\src\vctools\crt\crtw32\stdhpp\ostream @ 591]
0e 0000007d`b890fc00 00007fff`449a1c00 jsonout_plugin!std::endl<char,std::char_traits<char> >+0x43
0f 0000007d`b890fc30 00007ff7`2c93dbc5 jsonout_plugin!genint::jsonout_plugin::json_sink_node::execute+0x13c
10 0000007d`b890fd50 00007ff7`2c90f10c genintd!genint:ipeline::node_lifecycle_impl<1>::execute+0x2d
11 0000007d`b890fd80 00007ff7`2c9139eb genintd!genint:ipeline::node::thread_run+0x100
12 0000007d`b890fe80 00007ff7`2c914a36 genintd!boost::_bi::bind_t<void,std::mem_fun_t<void,genint:ipeline::node>,boost::_bi::list1<boost::_bi::value<genint:ipeline::node * __ptr64> > >:perator()+0x23
13 0000007d`b890fec0 00007ff7`2c95ebc3 genintd!boost::detail::thread_data<boost::_bi::bind_t<void,std::mem_fun_t<void,genint:ipeline::node>,boost::_bi::list1<boost::_bi::value<genint:ipeline::node * __ptr64> > > >::run+0x1a
14 0000007d`b890fef0 00007fff`4c12cd70 genintd!boost::system::system_category+0x53
15 0000007d`b890ff30 00007fff`520e13d2 ucrtbase!o__realloc_base+0x60
16 0000007d`b890ff60 00007fff`542254f4 kernel32!BaseThreadInitThunk+0x22
17 0000007d`b890ff90 00000000`00000000 ntdll!RtlUserThreadStart+0x34
do_open() is my function where i call this function
std::filebuf open().
ANybody has any idea why this kind of critical section deadlock can happen just while creating a filebuf
Same happens for this code as well..
std::fstream open("filename", std::ios::binary | std::ios::in | std::ios:ut);
# Child-SP RetAddr Call Site
00 000000d4`02bfdc78 00007ffb`8a6057ff ntdll!NtWaitForAlertByThreadId+0x14
01 000000d4`02bfdc80 00007ffb`8a605706 ntdll!RtlpWaitOnAddressWithTimeout+0x43
02 000000d4`02bfdcb0 00007ffb`8a605597 ntdll!RtlpWaitOnAddress+0xb2
03 000000d4`02bfdd20 00007ffb`8a5c4bf4 ntdll!RtlpWaitOnCriticalSection+0xdb
04 000000d4`02bfddf0 00007ffb`8a5c4b20 ntdll!RtlpEnterCriticalSectionContended+0xcc
05 000000d4`02bfde20 00007ffb`875061e0 ntdll!RtlEnterCriticalSection+0x40
06 000000d4`02bfde50 00007ffb`875060d5 ucrtbase!find_or_allocate_unused_stream_nolock+0xc4
07 000000d4`02bfde90 00007ffb`87502578 ucrtbase!__acrt_stdio_allocate_stream+0x25
08 000000d4`02bfdec0 00007ffb`7d3c1660 ucrtbase!common_fsopen<char>+0x4c
*** WARNING: Unable to verify checksum for ws-plugin.dll
09 (Inline Function) --------`-------- msvcp140!std::_Xfsopen+0x14 [d:\agent\_work\3\s\src\vctools\crt\crtw32\stdcpp\fiopen.cpp @ 17]
0a 000000d4`02bfdf10 00007ffb`61c4fc6f msvcp140!std::_Xfiopen<char>+0xe0 [d:\agent\_work\3\s\src\vctools\crt\crtw32\stdcpp\fiopen.cpp @ 90]
0b 000000d4`02bfdf40 00007ffb`61c4fd18 ws_plugin!std::basic_filebuf<char,std::char_traits<char> >:pen+0x43
0c 000000d4`02bfdfa0 00007ffb`61c4e1ed ws_plugin!std::basic_fstream<char,std::char_traits<char> >:pen+0x38
0d 000000d4`02bfdfd0 00007ffb`61c4e0fb ws_plugin!genint:ersistence::handle::do_open+0xe1
Has someone come across such problem ?
Continue reading...