Re: [reSIProcate] Bugs in SharedPtr and SharedCount of ReSip1.0 w hen using libCstd compiling(not libstlport4) on SOLARIS
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