Re: [Boost-users] [Thread] Interrupting a thread causes a segmentation fault

Subject: Re: [Boost-users] [Thread] Interrupting a thread causes a segmentation fault
From: Eric J. Holtman (eric_at_[hidden])
Date: 2011-02-22 12:28:41

On 2/22/2011 11:01 AM, W Frane wrote:

> 
> Do you mean more than one version of the same library, e.g., debug and release? 

Not this.

> manually define BOOST_THREAD_USE_LIB in my own program to use static
linking for the Thread library (see
https://svn.boost.org/trac/boost/ticket/4614), which seemed a bit off,
so it's possible there's something going wrong there (although I'd
expect it to affect the other aspects of the Thread library as well).
> 

I don't know if this is causing a problem or not.  What
happened to me, many moons ago, using MSVC, was this:

Main program, compiled and statically linked against the
C++ runtime library

DLL, compiled and statically linked against the same
C++ runtime library.

Then, main and DLL linked together.

Then, I'd call (for example), "malloc" from the
DLL, return that pointer to Main, and Main would
later call "free".

Since they had two distinct copies of everything in
the C++ runtime, that caused a very hard to diagnose
problem because the "free" would freak out when it
noticed the memory wasn't from it's own pool.

If you're doing something similar, and somehow getting
two distinct copies of the boost::thread library hard
linked into your program, I could see all sorts of ways
you would be in for a world of hurt.

I do not know enough about minGW to know if that's
even possible to do, but I'd check.

As a way to check, try doing something simple like
printing out the address of a global function or
a global variable in both Main and DLL.  If you
get different values, then you're probably in the
situation of having two copies around.