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



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]