Re: [sigc] test tarball: libsigc++ 2.0.6 (test1)



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]