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 23:06:09 +0000
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]