Re: [sigc] test tarball: libsigc++ 2.0.6 (test1)
- From: Martin Schulze <martin-ml hippogriff de>
- To: "Timothy M. Shead" <tshead k-3d com>
- Cc: libsigc-list gnome org
- Subject: Re: [sigc] test tarball: libsigc++ 2.0.6 (test1)
- Date: Fri, 08 Oct 2004 07:57:07 +0000
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:
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]