reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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

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@xxxxxxxxxx>

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel