Re: [sigc] test tarball: libsigc++ 2.0.6 (test1)
- From: "Timothy M. Shead" <tshead k-3d com>
- To: Martin Schulze <martin-ml hippogriff de>
- Cc: libsigc-list gnome org
- Subject: Re: [sigc] test tarball: libsigc++ 2.0.6 (test1)
- Date: Fri, 08 Oct 2004 14:58:31 -0700
Martin Schulze wrote:
Do I understand correctly that allocating an object via new from
within
a DLL, then destroying it via delete within a different module (EXE or
DLL) is the problem?
This is what I have been told. James Lin (jameslin vmware com) brought
up the problem.
One item looks suspicious to me, I see that in sigc++/functors/ slot.h,
the template struct typed_slot_rep<> has a static member function
"dup()" that is making a call to new, could this be a problem, since
it's inline code?
Hm, note that 'typed_slot_rep<>::dup()' is only called from
'slot_rep::dup()' (inline) via an indirect function call.
'slot_rep::dup()' is in turn only invoked from non-inline code in
slot_base.cc.
On second thought, this probably means that the code containing the
'new' is in the EXE module (where the template instantiations lie) but
invoked from the DLL module!?
The corresponding 'delete' is in the DLL module (slot_base::~slot_base).
Does this cause the problems? Then the solution would be to move the
'delete' in the EXE module. Please apply the attached patch (against
the test tarball or cvs) and try again.
Applied the patch, it doesn't seem to change the symptoms.
For everyone's reference, here is a discussion of this issue:
http://support.microsoft.com/default.aspx?scid=kb;en-us;122675
They offer four workarounds, it looks to me like their second suggestion
could be relatively elegant compared to SIGC_NEW_DELETE_IN_LIBRARY_ONLY
- override operator new and operator delete for the problem classes, and
call functions in the DLL to allocate/deallocate memory in their
implementations. I will poke at this and see what I come up with.
As an aside, I have verified that all tests pass if sigc++ is built as a
static library. If a DLL continues to be problematic, would you
consider adopting a static build so gtkmm-2.4 on MSVC can go forward?
Cheers,
Tim
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]