Hi all,
I'm having some issue with boost::wave::context: I have a function
called PreProcessSource, which allocates a boost::wave::context and
does some preprocessing; nothing fancy at all.
std::string PreProcessSource(const std::string& instring, const
std::string& defines)
{
typedef boost::wave::cpplexer::lex_token<> token_type;
typedef boost::wave::cpplexer::lex_iterator lex_iterator_type;
typedef boost::wave::context context_type;
std::string source = instring;
context_type ctx(source.begin(), source.end()); // DEADLOCK here
ctx.set_language(boost::wave::enable_emit_line_directives(ctx.get_language(),
true));
if(!defines.empty())
{
std::vectorstd::string tokens;
Splitstd::string(defines, tokens, ",");
std::vectorstd::string::const_iterator cit = tokens.begin();
for (;cit != tokens.end(); ++cit)
ctx.add_macro_definition(*cit);
}
context_type::iterator_type first = ctx.begin();
context_type::iterator_type last = ctx.end();
std::string outstring;
while (first != last)
{
const token_type::string_type& value = (*first).get_value();
std::copy(value.begin(), value.end(), std::back_inserter(outstring));
++first;
}
return outstring;
}
In the past it used to work fine, albeit with boost 1.47.0:
Library Nitro is a DLL that hosts the PreProcess source function, the
executable uses the Nitro DLL and can call PreProcess source, and
Nitro DLL can also sometimes call the function itself.
But right now this is no longer the case: whenever Nitro DLL calls the
function itself, or Nitro DLL calls another function, which in turn
calls back into Nitro DLL PreProcess function, it deadlocks.
If DO_DEADLOCK is defined to 1 in the following piece of code, the
deadlock will happen:
// In executable
class Tutorial01 : public Game
{
public:
// ...
Tutorial01()
: Game()
{
#if !DO_DEADLOCK
std::stringstream sstream;
sstream << "void main(inout float4 vtxInput : POSITION) { }"
<< std::endl << std::endl;
std::string source = sstream.str();
std::string defines = "";
std::string shaderCode = Nitro::PreProcessSource(source, defines);
#endif
}
void LoadContent()
{
#if DO_DEADLOCK
std::stringstream sstream;
sstream << "void main(inout float4 vtxInput : POSITION) { }"
<< std::endl << std::endl;
std::string source = sstream.str();
std::string defines = "";
std::string shaderCode = Nitro::PreProcessSource(source, defines);
#endif
// Original code that deadlocks too.
// Calls in the DLL, which will call PreProcessSource.
// effect->Initialize(device, source, "DX11");
}
// ...
};
int APIENTRY wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPWSTR lpCmdLine, int nCmdShow)
{
Tutorial00 app;
app.Run();
return 0;
}
Note that the constructor is called directly from the executable,
whereas LoadContent is called from the DLL:
// In Nitro DLL
void Game::Run()
{
try
{
// ...
LoadContent();
// ...
} catch(/* ... */) { }
}
The code is compiled for x64 and in debug mode. I compile boost myself
into a DLL (using bcp to get the files for the libraries I use) with
the following options:
Preprocessor:
WIN32
BOOST_ALL_NO_LIB
BOOST_ALL_DYN_LINK
BOOST_THREAD_BUILD_DLL
_DLL
_DEBUG
_WINDOWS
_USRDLL
Code Generation:
C++ Exceptions (/EHsc)
Multi-threaded Debug DLL (/MDd)
Function-level linking (/Gy)
Streaming SIMD Extensions 2 (/arch:SSE2) (/arch:SSE2)
Fast floating point model (/fp:fast)
DLL A uses the same code gen options, and has the following
preprocessor macros defined:
_WINDLL
_UNICODE
UNICODE
WIN32
_WINDOWS
BOOST_ALL_NO_LIB
_DEBUG
The executable and unit test executable uses the same code gen
options, and have the following preprocessor macros defined:
BOOST_ALL_NO_LIB
UNICODE
_UNICODE
_MBCS
I have tried various combinations of preprocessor definitions (with
_DEBUG and without, with BOOST_THREAD_USE_DLL, and without; to no
avail).
Here is the (cleaned up) stack trace of the deadlock:
ntdll.dll!0000000076dc135a()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
KernelBase.dll!000007fefd4f10dc()
Nitro.dll!boost::call_once(boost::once_flag &
flag, void (void)* f) Line 197 + 0x18 bytes C++
Nitro.dll!boost::call_once(void (void)* func, boost::once_flag & flag)
Line 28 C++
Nitro.dll!boost::spirit::classic::static_boost::spirit::classic::space_parser::parse
... Line 136 C++
Nitro.dll!boost::spirit::classic::parse &
instring, const
std::basic_string &
defines) Line 51 + 0xa0 bytes C++
Tutorial01.exe!Tutorial01::LoadContent() Line 70 + 0x33 bytes C++
Nitro.dll!Nitro::Game::Run() Line 40 C++
Tutorial01.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 149 C++
Tutorial01.exe!__tmainCRTStartup() Line 547 + 0x42 bytes C
Tutorial01.exe!wWinMainCRTStartup() Line 371 C
kernel32.dll!00000000766a652d()
ntdll.dll!0000000076d9c521()
It seems boost::wave is trying to parse some time stamp, and by doing
so instantiates a grammar and that's when things seem to go bad.
The deadlock happens inside the constructor of the context type, and
the Visual Studio debugger points me to line 197 in
boost\thread\win32\once.hpp
BOOST_VERIFY(!::boost::detail::win32::WaitForSingleObject(
event_handle,::boost::detail::win32::infinite));
When called directly from the executable, I have noticed that the
once_flag.status value is 0, and it exits the loop on the first
iteration, whereas when it's called from inside the DLL, the
once_flag.status value is 53, and it goes around the loop twice before
falling into the WaitForSingleObject. I'm not sure if that's even
relevant but I've exhausted all the possibilities and I'm out of
ideas.
I'd be grateful if anyone could shed some light on this.
Best Regards,
Julien Lebot
