< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

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


Sounds like the easy way to fix this is to wrap the stuff in an #ifdef. From what I read, libCstd is not as standards-compliant as STLport, and I imagine this issue could be caused by this lack of compliance (I am just theorizing though; this could be an entirely different issue). What compiler variable is used to indicate that libCstd is being used?

Best regards,
Byron Campen

 
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.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
_______________________________________________
resiprocate-devel mailing list

Attachment: smime.p7s
Description: S/MIME cryptographic signature