OpenSlide crashes when used in third-party application including boost/thread/future.hpp

[GeertLitjens]

I'm trying to use OpenSlide in our software, which is linked against a third party library. When compiling a simple test program under Windows (VC11)

include "openslide.h"

include < iostream >

using namespace std;

int main(int argc, char* argv[])
{
cout << "Openslide version: " << endl;
cout << openslide_get_version() << endl;
cout << "Program completed" << endl;
return 0;
}

this will work. However, the third-party software links against boost/thread, and adding the line

include "boost/thread/future.hpp"

will cause the program to crash at the openslide_get_version() line. Inspecting it with a debugger shows that libopenslide will not be loaded in this case. I compiled openslide using Cygwin and the winbuild scripts on the same system. Anybody any guesses why this is happening? My own best guess up till now is that boost/thread/future.hpp uses rvalues and maybe the executable resulting from compiling Cx11 with VC11 is incompatible with the libopenslide.lib compiled with MinGWx64? And that not including future.hpp will result in a compiled executable with more backward compatibility? Any help would be greatly appreciated.

[GeertLitjens]

Update: this also happens with VC9 (Visual Studio 2008)

[bgilbert]

So adding/removing the future.hpp include is sufficient to make OpenSlide not work/work? Strange.

I don't have an explanation, but I'd suggest investigating why libopenslide isn't being loaded. Does the system try to load the library, and fail? Does it not even try? Does the EXE declare linkage against OpenSlide?

[GeertLitjens]

If I put the exe in Dependency Walker, in both situations it declares linkages against libopenslide-0.dll. However, if you click on libopenslide in Dependency Walker you can see that when including future.hpp the actual functions are not linked (in the example openslide_get_version). See attached images. I narrowed down the problematic part of futures.hpp. When you remove this part from the .hpp:

            all_futures_lock(std::vector<registered_waiter>& futures):
                count(futures.size()),locks(new boost::unique_lock<boost::mutex>[count])
            {
                for(count_type i=0;i<count;++i)
                {
                    locks[i]=boost::unique_lock<boost::mutex>(futures[i].future->mutex);
                }
            }

it also works. I honestly have no clue why this is happening, but I guess it has something to do with compiler incompatibility. Any suggestions on what to try?

[bgilbert]

Are you linking your test program with /OPT:REF? We've had problems with that option in the past, and perhaps they were not completely fixed. Try /OPT:NOREF.

More generally, you could try playing with compiler and linker options (disabling optimization, etc.).

[GeertLitjens]

Experimented both with /OPT:NOREF and several optimization switches, none of them solve the problem. Very strange issue...

[bgilbert]

Argh. Some thoughts on hacky workarounds:

• Create two object files: one that uses boost/thread and one that calls OpenSlide. Link them together.
• As a last resort: call OpenSlide through LoadLibrary/GetProcAddress.

Do either of those work?

[GeertLitjens]

Great, both solutions work! A bit hacky, but especially the first one seems workable. Thanks for your help. Of course I'm still wondering whats going on in the linker when including both boost-thread and OpenSlide, I put it on verbose, no warnings whatsover. Well, this solves this problem for me at least.

[bgilbert]

Closing as fixed by openslide/openslide-bin@20a3d46e via #125. Please post a comment if you see this again.