Hi Malcolm,
it's great that you finally nailed down the culprit. As you have
invested quite some time to it and as there are MICO users here and
there asking for STLport support, could you be so kind and test a change
where either you change default ctor of CurrentState to be private or
create "default" assignment operator with assert(0) as you describe? If
this goes well I'm in favor of private default ctor. If you are lucky
with the change and it runs fine on top of your STLport, please send me
the patch (or whole file) and I'll test it here and include (if it does
not break anything).
Thanks!
Karel
Malcolm Davey wrote:
> Hi Karel
>
> I think I have finally resolved the issue - it's a combination of using
> mico with stlport when type traits are enabled to do optimized copying
> of items in std containers and algorithms.
>
> (in mico 2.3.13 )
> The problem occurs in poa_impl.cc
> On the line 418
> current->push_back (CurrentState (_poa, _por, _serv));
>
> The previous sample code I sent with multiple calls to bind_new_context
> will exercise the problem, because it results in multiple CurrentState
> objects being added to the container in question.
>
> I think there is a problem with stlport when it tries to optimize the
> insertion in the push_back. It does a check to see if the class in
> question (in our case CurrentState) has a trivial assignment operator -
> which it does, and then optimizes in the case where the vector needs to
> do a reallocation. When it is optimized it does a call to clear() hence
> calling CurrentState's destructor for items already in the container
> hence decreasing the reference count of serv.
> It then does a copy assuming it can do a memcpy, skipping the actual
> copy constructor and skipping the add_ref on the serv object.
> This results in the serv object ultimately being deleted while it is
> still in use.
> It seems the problem is in stlport (at least as far back as 5.1.5 and in
> the current one - 5.2). The test in the stlport code should be to
> determine if there is a trival copy constructor NOT assignment operator.
> To avoid the issue on mico's side, adding an assignment operator (with
> an assert(0) like the default constructor) would avoid the issue - its
> generally not common to have just. Making the default constructor or
> assignment operator private and not define them might be an even better
> option - I haven't test this yet and am not sure if it avoids the issue
> with stlport.
>
>
> (in stlport _vector.h)
>
> void push_back(const _Tp& __x) {
> if (this->_M_finish != this->_M_end_of_storage._M_data) {
> _Copy_Construct(this->_M_finish, __x);
> ++this->_M_finish;
> }
> else {
> typedef typename
> __type_traits<_Tp>::has_trivial_assignment_operator _TrivialCopy;
> _M_insert_overflow(this->_M_finish, __x, _TrivialCopy(), 1UL,
> true);
> }
> }
>
> This issue could happen with earlier versions of mico, but we had type
> traits in stlport off initially because it caused mico to not compile.
> Later we made a change to our stlport headers to enable mico to compile
> with type traits. This change is in stlport 5.2. Some other OS's might
> not enable type traits with stlport and hence might avoid the issue.
>
> Malcolm
>
>
>
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
_______________________________________________
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
