A
Arnaud Debaene
Hello,
I think I found a bug in VC 7.1 concerning destruction of stack
objects when linking a static, non managed, C++ library within a
managed C++ application. Here is a repro case :
1) Build a static, unmanaged, library containing the following 2
files. Compiles with /MDd.
// FILE BaseHolder.h
#pragma once
#include <boost/shared_ptr.hpp>
class Base
{};
class Derived : public Base
{};
class Holder
{
public:
Holder(boost::shared_ptr<Base> pointer);
private:
boost::shared_ptr<Base> my_pointer;
};
//FILE BaseHolder.cpp
#include "StdAfx.h"
#include ".\baseholder.h"
}
2) Build a MC++ console application with the following main file (also
compiles with /MDd) :
#include "stdafx.h"
#using <mscorlib.dll>
#include <boost/shared_ptr.hpp>
#include "../static_lib/BaseHolder.h"
void Function()
{
boost::shared_ptr<Derived> pointer (new Derived); //line 1
Holder my_holder (pointer); //line 2
}
int _tmain()
{
Function();
return 0;
}
3) Now, put breakpoints on boost::detail::sp_counted_base::add_ref()
and boost::detail::sp_counted_base::release() to see the shared_ptr
counter goes up and down : these are lines 119 and 129 of
shared_count.hpp in my version of Boost()
Run the program and observes the behaviour :
1) On line 2, add_ref() is called when copying a copy of pointer for
the parameter of Holder constructor.
2) BUG!!! release() is called from somewhere deep inside mscorwks.dll.
There is no shared_ptr to be destroyed at this point (the Holder
contructor has not yet been called).
3) The Holder constructor is called
4) add_ref is called during construction of Holder::my_pointer (counst
is now 2, should be 3).
5) Normal stuff continues (the parameter of Holder constructor is
destroyed, etc etc...). However, we have leaked an abnormal release,
and the program hangs (in
boost::detail::lightweight_mutex::scoped_lock constructor) during
leaving Function, when trying to delete twice the shared_ptr counter.
If you compile the main application as traditionnal C++ (not managed),
everything goes smooth, so I believe the problem lies somewhere within
mscorwks.dll.
If anyone has an idea on a workaround...
Arnaud
MVP - VC
I think I found a bug in VC 7.1 concerning destruction of stack
objects when linking a static, non managed, C++ library within a
managed C++ application. Here is a repro case :
1) Build a static, unmanaged, library containing the following 2
files. Compiles with /MDd.
// FILE BaseHolder.h
#pragma once
#include <boost/shared_ptr.hpp>
class Base
{};
class Derived : public Base
{};
class Holder
{
public:
Holder(boost::shared_ptr<Base> pointer);
private:
boost::shared_ptr<Base> my_pointer;
};
//FILE BaseHolder.cpp
#include "StdAfx.h"
#include ".\baseholder.h"
{Holder::Holder(boost::shared_ptr said:
}
2) Build a MC++ console application with the following main file (also
compiles with /MDd) :
#include "stdafx.h"
#using <mscorlib.dll>
#include <boost/shared_ptr.hpp>
#include "../static_lib/BaseHolder.h"
void Function()
{
boost::shared_ptr<Derived> pointer (new Derived); //line 1
Holder my_holder (pointer); //line 2
}
int _tmain()
{
Function();
return 0;
}
3) Now, put breakpoints on boost::detail::sp_counted_base::add_ref()
and boost::detail::sp_counted_base::release() to see the shared_ptr
counter goes up and down : these are lines 119 and 129 of
shared_count.hpp in my version of Boost()
Run the program and observes the behaviour :
1) On line 2, add_ref() is called when copying a copy of pointer for
the parameter of Holder constructor.
2) BUG!!! release() is called from somewhere deep inside mscorwks.dll.
There is no shared_ptr to be destroyed at this point (the Holder
contructor has not yet been called).
3) The Holder constructor is called
4) add_ref is called during construction of Holder::my_pointer (counst
is now 2, should be 3).
5) Normal stuff continues (the parameter of Holder constructor is
destroyed, etc etc...). However, we have leaked an abnormal release,
and the program hangs (in
boost::detail::lightweight_mutex::scoped_lock constructor) during
leaving Function, when trying to delete twice the shared_ptr counter.
If you compile the main application as traditionnal C++ (not managed),
everything goes smooth, so I believe the problem lies somewhere within
mscorwks.dll.
If anyone has an idea on a workaround...
Arnaud
MVP - VC