[reSIProcate] Bugs in SharedPtr and SharedCount of ReSip1.0 when using libCstd compiling(not libstlport4) on SOLARIS

Zhao Li,SCNB R&D NC(BJ) zhaoli at siemens.com
Tue Jan 9 20:39:04 CST 2007


 
We have to use libCstd to compile and link our program on Solaris, so we adapt resip a little in order to compile it succesfully.
But when running, core dump occurs, we consider it is SharedCount error. So we write a test case like below
 
#include "rutil/SharedPtr.hxx"
class TestSharedPtr
{
    protected:
    int attr1;
    
};
class TestSharedPtrA : public TestSharedPtr
{
    protected:
    int attr2;
 
};
 
int
main(int argc, char** argv)
{
    int temp2 = 0;
    int temp3 = temp2;
    int temp4 = temp2;
    
    SharedPtr <TestSharedPtrA> Ptr1;
    SharedPtr <TestSharedPtr> Ptr2;
    SharedPtr <TestSharedPtr> Ptr5;
    SharedPtr <TestSharedPtrA> ptrptr (new  TestSharedPtrA);
    Ptr1 = ptrptr;
    Ptr2 = ptrptr;
    Ptr5 = Ptr2;
    
    SharedPtr <TestSharedPtrA> Ptr3;
    SharedPtr <TestSharedPtr> Ptr4;                                                     
    SharedPtr <TestSharedPtrA> ptrptr1 (new  TestSharedPtrA);
    Ptr3 = ptrptr1;                        // Here, the program core dump. but we think stack error has already occurs before.
    Ptr4 = ptrptr1;
}
 
(I have to say, the codes above runs succesfuly under GCC and VC7 and SUN CC with stlport4.)
 
we check the SharedCount.hxx again and again, then find the bugs:
 
   void * operator new(size_t)
   {
      return std::allocator<this_type>().allocate(1, static_cast<this_type *>(0));
   }
 
   void operator delete(void * p)
   {
      std::allocator<this_type>().deallocate(static_cast<this_type *>(p), 1);
   }
If we delete these codes, the program runs smoothly. 
 
 
So we check the SUN CC stl library <memory>, where std::allocator is defined.
#ifdef _RWSTD_ALLOCATOR 
 template <class T>
  class allocator
  { 
    pointer allocate(size_type n, allocator<void>::const_pointer = 0)
    { 
      pointer tmp =
      _RWSTD_STATIC_CAST(pointer,(::operator 
                                  new(_RWSTD_STATIC_CAST(size_t,(n * sizeof(value_type))))));
      _RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc);
      return tmp;
    } 
}
#else
  template <class T>
  class allocator
  { 
    void * allocate (size_type n, void *  = 0)
    { 
      void * tmp = _RWSTD_STATIC_CAST(void*,(::operator new(_RWSTD_STATIC_CAST(size_t,(n)))));
      _RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc);
      return tmp;
    } 
}
It is the GREEN codes bring out the BUGS.
 
We also checked the BOOST codes "sp_counted_impl.hpp", It defined operator new and delete of sp_counted_impl_p as these:
#if defined(BOOST_SP_USE_QUICK_ALLOCATOR)
    void * operator new( std::size_t )
    {
        return quick_allocator<this_type>::alloc();
    }
 
    void operator delete( void * p )
    {
        quick_allocator<this_type>::dealloc( p );
    }
#endif
 
We think the new and delete operator of  sp_counted_base_impl in "rutil/SharedPtr.hxx" can be removed safely. Is It?
 
By the way, can reSipRocate distribute a version which don't depend on STLPORT4, because very very many third party libs are build by libCstd. It is not difficult to adapt reSip.
 
Thank you.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070110/8e1e211b/attachment.htm>


More information about the resiprocate-devel mailing list