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

[Martin Schulze <martin-ml hippogriff de>]

Am 07.10.2004 20:52:53 schrieb(en) Timothy M. Shead:
> 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?

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.

Regards,

 Martin

? libsigc++-2.0.6
? stamp-h.in
? stamp-h1
? the_diff
? scripts/libtool.m4
? scripts/ltoptions.m4
? scripts/ltsugar.m4
? scripts/ltversion.m4
Index: sigc++/functors/slot_base.cc
===================================================================
RCS file: /cvs/gnome/libsigc++2/sigc++/functors/slot_base.cc,v
retrieving revision 1.4
diff -u -3 -r1.4 slot_base.cc
--- sigc++/functors/slot_base.cc	2 Oct 2004 18:29:05 -0000	1.4
+++ sigc++/functors/slot_base.cc	8 Oct 2004 07:54:04 -0000
@@ -75,11 +75,13 @@
     rep_ = src.rep_->dup();
 }
 
+#ifndef SIGC_NEW_DELETE_IN_LIBRARY_ONLY // only defined for non-MSVC platforms to keep ABI compatibility
 slot_base::~slot_base()
 {
   if (rep_)
     delete rep_;
 }
+#endif
 
 slot_base::operator bool() const
 {
Index: sigc++/functors/slot_base.h
===================================================================
RCS file: /cvs/gnome/libsigc++2/sigc++/functors/slot_base.h,v
retrieving revision 1.6
diff -u -3 -r1.6 slot_base.h
--- sigc++/functors/slot_base.h	2 Oct 2004 18:29:05 -0000	1.6
+++ sigc++/functors/slot_base.h	8 Oct 2004 07:54:04 -0000
@@ -230,7 +230,12 @@
    */
   slot_base(const slot_base& src);
 
+#ifdef SIGC_NEW_DELETE_IN_LIBRARY_ONLY // only defined for MSVC to keep ABI compatibility
+  inline ~slot_base()
+    { if (rep_) delete rep_; }
+#else
   ~slot_base();
+#endif
 
   /** Tests whether a slot is null, because the default constructor was used.
    * Test a slot for null like so: