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

[Byron Campen]

	I need something I can feed to a #ifdef in the code, to  
conditionally compile out the offending lines. Is there anything like  
this?

Best regards,
Byron Campen

>
> Just remove '-library=stlport4' from current makefile of Sun CC.
> Thank you.
>
> _____________________________________________________
> SIEMENS
>                                     Siemens Communication Networks  
> ltd., Beijing
>                                     R&D Network Core
>                                     No. 14 Jiuxianqiao Road,  
> Chaoyang District.
>                                     P.O.Box 100016-14
>                                     Beijing 100016, P.R. China
>                                     Tel: (+86)-10-58671326
> Friendly Greetings  Fax: (+86)-10-58421043
> Zhao Li (Lawrence)  E-mail: zhaoli at siemens.com
> _____________________________________________________
>> -----Original Message-----
>> From: Byron Campen [mailto:bcampen at estacado.net]
>> Sent: Friday, February 02, 2007 12:31 AM
>> To: Zhao Li,SCNB R&D NC(BJ)
>> Cc: resiprocate-devel at list.sipfoundry.org
>> Subject: 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
>>> resiprocate-devel at list.resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>

-------------- 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/20070209/7d4f4686/attachment.bin>