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

[Byron Campen]

	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
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070201/4de62bc2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070201/4de62bc2/attachment.bin>