Boost :: signal memory access error

Question

I try to use boost :: signal to implement the callback mechanism, and I get confirmation of memory access in boost :: signal code even with the simplest use of the library. I simplified it to this code:

#include <boost/signal.hpp> typedef boost::signal<void (void)> Event; int main(int argc, char* argv[]) { Event e; return 0; } 

Thanks!

Edit: this was Boost 1.36.0 compiled using Visual Studio 2008 w / SP1. Boost :: filesystem, for example boost :: signal, also has a library to connect to, and it seems to work fine. I believe all the other boost libraries that I use are headers.

Answer 1

I tested your code on my system and it works great. I think there is a mismatch between your compiler and the compiler on which your Boost.Signals library is built. Try loading the Boost source and compile Boost.Signals using the same compiler as you used to generate the code.

For my information only, which compiler (and version) are you using?

Answer 2

I confirmed this as a problem - Stephan T Lavavej (STL!) At Microsoft reported this .

In particular, he said:

A common problem is that the linker does not diagnose any violation of the definition rule (ODR). Although this is not impossible, it is a difficult problem to solve, therefore, the Standard specifically allows certain ODR violations to be undiagnosed.

I would really like the compiler and linker to have a special mode that would catch all ODR violations during the build, but I admit that this will be difficult to achieve (and will consume resources that could possibly be delivered even better using, like more conformity). In any case, ODR violations can be avoided without much effort by properly structuring our code, so we, as programmers, will cope with this lack of linker verification.

However, macros that change the functionality of the code when turned on and off dangerously flirt with ODR, and a particular problem is that _SECURE_SCL and _HAS_ITERATOR_DEBUGGING do just that. At first glance, this may not seem so bad, since you should already have control over which macros are defined throughout your build system. However, separately compiled libraries complicate matters - if you created (for example) Boost with _SECURE_SCL, by default, your project should not disable _SECURE_SCL. If you intend to disable _SECURE_SCL in your project, now you need to rebuild Boost accordingly. And depending on the particular library in question, this can be difficult (with Boost, in my opinion, this can be done, I just never understood how to do this).

He lists some possible workarounds later in the commentary, but none of them are suitable for this situation. Someone else said they could turn off these flags when compiling boost by inserting some definitions into boost / config / compiler / visualc.hpp , but for me this worked NOT . However, pasting the next VERBATIM line into tools / build / v2 / user-config.jam did the trick. Please note that spaces are important for increasing jam.

  using msvc: 9.0:: <cxxflags> -D _SECURE_SCL = 0 <cxxflags> -D _HAS_ITERATOR_DEBUGGING = 0;

Answer 3

This problem often occurs when compiling with a different heap implementation. In VS, you can request that the CRT be linked in (as a static library) or left as a dynamic library.

If the library that you use allocates memory in its associated heap and your program tries to free it using another heap, you have problems: the object to be freed is not included in the list of objects that were allocated.

Answer 4

Brian, I just experienced the same problem as you. Thanks to your answer on a blog post I tracked it down to turn off _HAS_ITERATOR_DEBUGGING and _SECURE_SCL .

To fix this problem, I created boost libraries manually. I did not need to interfere with the configuration files. Here are two lines I use:

x86
bjam debug release link = static threading = multi runtime-link = shared Define = _SECURE_SCL = 0 Define = _HAS_ITERATOR_DEBUGGING = 0 - stage with signals

64
bjam debug release link = static threading = multi runtime-link = shared Define = _SECURE_SCL = 0 Define = _HAS_ITERATOR_DEBUGGING = 0 model-address = 64 - stage with signals

This creates the following files:
libboost_signals-vc90-m-1_43.lib
libboost_signals-vc90-mt-gd-1_43.lib

Hope this helps.