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

["Timothy M. Shead" <tshead k-3d com>]

Martin Schulze wrote:
> Am 04.10.2004 21:33:33 schrieb(en) Timothy M. Shead:
> > Unfortunately even with the patch I see the same
> > memory-allocation-related segfaults in the tests as with 2.0.5.   Could
> > you point me in the direction of the new/delete changes you made?
> > I'll see if anything stands out.
>
> It was the following change:
>
> 2004-10-02  Martin Schulze <mschulze cvs gnome org>
>
>     * sigc++config.h.in, MSVC_Net2003/sigc++config.h,
>     sigc++/signal_base.cc, sigc++/functors/slot_base.{h,cc},
>     sigc++/functors/macros/slot.h.m4: Define and use new macro
>     SIGC_NEW_DELETE_IN_LIBRARY_ONLY to ABI-compatibly move
>     all calls to new and delete into non-inline library code.
>
> In signal_base.cc the internal signal implementation object is  
> allocated/freed (signal_base::impl/signal_base::destroy).
> In slot_base.cc the internal slot representation object is allocated/ 
> freed (various calls to slot_rep::dup / slot_base::~slot_base).
> I can't think of any other calls to new/delete in the library.

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?

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?

Cheers,
Tim