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

[Martin Schulze <martin-ml hippogriff de>]

Am 08.10.2004 23:58:31 schrieb(en) Timothy M. Shead:
> 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.

Strange - logic fails! Well, on the other hand this is MS ...

> 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.

Go ahead.

> 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?

Sure - we don't want to give up support for MSVC. However if others can  
solve this problem we should also be able to do so.

Regards,

 Martin