[log] unspecified error when going from win7 to xp
Hi, forgive me if the following error description is too vague. We are currently using boost.log (exported on 2010/05/20, compiled with msvc 9.0 sp1 on win7 against boost 1.40.0) in a large C++ project. On top of this C++ project a C-API is placed to ease integration with .NET's pInvoke technology. This C-API consists of very primitive methods. Integration with .NET (2.0 or 3.x does not matter) works fine on win7. But when the executables are moved to a windows xp (or lower) based platform (with all redistributables installed) it breaks with an AccessViolationException. We tracked down the problem (without the ability to debug :) to the usage of BOOST_LOG_FUNCTION and/or BOOST_LOG_NAMED_SCOPE. If those macros are not used, everything works fine again. I know my description is vague, but maybe someone has an idea if the problem is us or the problem could rely in those macros. Help is desperately needed. Best regards, Christoph
On 05/27/2010 07:38 PM, Christoph Heindl wrote:
Hi,
forgive me if the following error description is too vague.
We are currently using boost.log (exported on 2010/05/20, compiled with msvc 9.0 sp1 on win7 against boost 1.40.0) in a large C++ project.
On top of this C++ project a C-API is placed to ease integration with .NET's pInvoke technology. This C-API consists of very primitive methods. Integration with .NET (2.0 or 3.x does not matter) works fine on win7. But when the executables are moved to a windows xp (or lower) based platform (with all redistributables installed) it breaks with an AccessViolationException.
We tracked down the problem (without the ability to debug :) to the usage of BOOST_LOG_FUNCTION and/or BOOST_LOG_NAMED_SCOPE. If those macros are not used, everything works fine again.
I know my description is vague, but maybe someone has an idea if the problem is us or the problem could rely in those macros.
Help is desperately needed.
What version of the library do you use? Is it used in a context when its binary is dynamically loaded? If so, try disabling compiler-supplied TLS by defining BOOST_LOG_NO_COMPILER_TLS. If that doesn't help, then please register a trac ticket with a stack of the crash. I'll take a look. BTW, are the BOOST_LOG_FUNCTION/BOOST_LOG_NAMED_SCOPE macros only used from pure C++ code?
On Thu, May 27, 2010 at 9:50 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
What version of the library do you use? Is it used in a context when its binary is dynamically loaded? If so, try disabling compiler-supplied TLS by defining BOOST_LOG_NO_COMPILER_TLS.
I'm using rev479, since it is the last one compatible with boost 1.40.0. I recompiled the library using BOOST_LOG_NO_COMPILER_TLS today and it solves my problem indeed! I've read about the define but considered it irrelevant for my case until now: PInvoke on .NET uses delay-loading. Still interesting that error did not occur on Windows7. Thanks for your help, I greatly appreciated it!
BTW, are the BOOST_LOG_FUNCTION/BOOST_LOG_NAMED_SCOPE macros only used from pure C++ code?
Yes. Best regards, Christoph
On 05/29/2010 12:21 PM, Christoph Heindl wrote:
On Fri, May 28, 2010 at 3:57 PM, Andrey Semashev<andrey.semashev@gmail.com>
Windows Vista and later have this problem solved, so there's no need in this macro on these platforms.
do you have reference to the particular issue involved?
http://msdn.microsoft.com/en-us/library/2s9wt68x.aspx In the last paragraph it is said that the issue is only relevant to Windows prior to Vista.
On Sat, May 29, 2010 at 10:44 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
http://msdn.microsoft.com/en-us/library/2s9wt68x.aspx
In the last paragraph it is said that the issue is only relevant to Windows prior to Vista.
Thanks for the info!
participants (2)
-
Andrey Semashev -
Christoph Heindl