Quoting Paul Bergen <bergen.p0@gmail.com>:
[...] If a seasoned Boost dev agrees to do it, I'll send you money by paypal first, then give you VNC access to my dev box so you can login and see for yourself what's happening. My email is bergen.p0@gmail.com.
Basically, I use bjam like this:
bjam toolset=msvc-9.0 variant=release threading=multi link=shared --with-system --with-thread --with-date_time --with-regex --with-serialization stage
then every time I do anything socket related, it crashes in xmemory, deallocate with the following backtrace:
ntdll.dll!77eefadc() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!77eb272c() ntdll.dll!77e7e1ef()
This smells a bit like link-incompatible compiler options. You might want to make sure you're passing in identical options to your client application as is passed in when building the boost library itself. Particularly important in this case, I imagine, is that both your app and boost links against the run-time library the same way (i.e. statically vs. dynamically, and on windows you have to make sure both debug/release and multi-threaded/single-threaded match as well). The difficult way of doing this is to invoke bjam with -n and look into all the response files (.rsp) and make sure the same settings are passed in when you build the source files of your app. The probably slightly simpler way of solving this (or at least to verify if this is in fact the issue) is to build boost and your app with the same build tool. Either drag all the boost source files you need into your project or build your project with boost build (the latter is probably slightly more reliable). Given that you're building boost with link=shared, make sure you're linking against the multithreaded-release-DLL-runtime library in visual studio as well. -- Arvid Norberg