[reSIProcate] Is this the cause of random solaris cores from resip related to memory?

[Alan Hawrylyshen]

Sandeep,
It sure looks like this could be a real problem.
One thing that might be a good overall improvement would be to:

a) Create a class / abstraction for time services.
b) Implement the OS specific time calls within this class.
c) Provide a 'cheap' time interface for places that need rough time and
    the more precise time can call through to the underlying OS.
By controlling access to the time functions in a single class, we can  
either
use the MT safe routines or ensure serial access to those that are not.

A
On 27-Oct-05, at 18:05 , Sandeep Sharma wrote:

> Hello,
>
> I am using a resip version from April and seeing random cores on  
> solaris
> under load. This is what I have found so far. Experts, please chime  
> in..
>
> Running a MT application based on resiprocate on solaris multi- 
> processor
> box results in random core dumps. On running purify, I see lot of MRE
> (malloc re-entered). Doing some investigation, found a Sun article  
> that
> says that the following calls are not MT safe and should not be  
> used. I
> did a quick grep and found resip does use localtime and gmtime  
> (without
> the _r at the end). I have not checked the others..
> This is the link if anyone is interested..
> http://developers.sun.com/solaris/articles/multithreaded.html
>
> --------
> ctime, localtime, gmtime, asctime, strtok, gethostbyname,  
> gethostbyaddr,
> getservbyname, getservbyport, getprotobyname, getnetbyname,
> getnetbyaddr, getrpcbyname, getrpcbynumber, getrpcent, rand, ctermid,
> tmpnam, readdir, getlogin, getpwent, getpwnam, getpwuid, getspent,
> fgetspent, getspnam, getgrnam, getgrgid, getnetgrent, getrpcbyname,
> tempnam, fgetpwent, fgetgrent, ecvt, gcvt, getservent, gethostent,
> getgrent, fcvt
> --------
>
> Does it make sense that my cores may be caused by the above? I have  
> been
> seeing random core dumps related to malloc and free on solaris, and  
> most
> of them have been related to:
>
>       This is occurring while in thread 28:
>             tzcpy          [time_comm.c]
>             getzname       [time_comm.c]
>             _ltzset_u      [time_comm.c]
>             mktime         [libc.so.1]
>             strftime       [libc.so.1]
>             resip::Data&resip::Log::timestamp(resip::Data&)
> [Log.cxx:280]
>             resip::Data resip::Log::timestamp() [Log.cxx:245]
>             std::basic_ostream<char,std::char_traits<char>
>
>> &resip::Log::tags(resip::Log::Level,const resip::Subsystem&,const
>>
> char*,int,std::basic_ostream<char,std::char_traits<char> >&)
> [Log.cxx:227]
>             void
> resip::ConnectionBase::preparseNewBytes 
> (int,resip::Fifo<resip::TransactionMessage>&) [ConnectionBase.cxx:191]
>             int
> resip::Connection::read(resip::Fifo<resip::TransactionMessage>&)
> [Connection.cxx:128]
>             void
> resip::TcpBaseTransport::processSomeReads(resip::FdSet&)
> [TcpBaseTransport.cxx:146]
>             void resip::TcpBaseTransport::process(resip::FdSet&)
> [TcpBaseTransport.cxx:270]
>             void resip::TransportSelector::process(resip::FdSet&)
> [TransportSelector.cxx:188]
>             void resip::TransactionController::process(resip::FdSet&)
> [TransactionController.cxx:79]
>             void resip::SipStack::process(resip::FdSet&)
> [SipStack.cxx:400]
>
>
>
>
> -- 
> Sandeep Sharma <ssharma at jabber.com>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>