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

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	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@xxxxxxxxxxx
> _____________________________________________________
> > -----Original Message-----
> > From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> > Sent: Friday, February 02, 2007 12:31 AM
> > To: Zhao Li,SCNB R&D NC(BJ)
> > Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxxx
> > > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

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