I briefly looked at the code and the likelihood of a hog getting into a
frenzy is this place (see snippet below).
1. If the readBuffer is non-null after the last read iteration, then it
is residual. This can happen if the sip packet has extra bytes
overruning the actual content length it announced. This will be
consumed by the next read interation.
2. If there is always available new data prior to call to poll, then
poll would return right away and call POLLIN.
One can easily, intentionally, reproduce this by opening a TCP socket to
port 5060 and send it garbage in a perpetual loop and get the hog in frenzy.
if (!readBuffer.isNull())
{
fds[1].revents = POLLIN;
}
else
{
// Otherwise, call poll() to wait.
int resPoll = poll(&fds[0], sizeof (fds) / sizeof (fds[0]),
POLL_TIMEOUT);
assert(resPoll >= 0 || (resPoll == -1 && errno == EINTR));
if (resPoll != 0)
{
OsSysLog::add(FAC_SIP, PRI_DEBUG,
"SipClient[%s]::run "
"resPoll= %d revents: fd[0]= %x fd[1]= %x",
mName.data(),
resPoll, fds[0].revents, fds[1].revents );
}
}
On 12/02/2010 12:08 AM, Domenico Chierico wrote:
> Hi,
>
> In this days I've worked on a problem in sipXproxy, that goes up to 100%
> of cpu usage, after some test i found the source of the problem into:
>
> SipClient::run() /* sipXtackLib */
>
> logs says:
>
>> "2010-11-23T15:49:46.439195Z":15308:KERNEL:DEBUG:delcoops.delcospa.net:SipClientTcp-36:B4FFFB70:SipXProxy:"OsSocket::isReadyToWrite
>> poll returned 1 in socket: 46 0xb6f57690"
>> "2010-11-23T15:49:46.439251Z":15309:SIP:DEBUG:delcoops.delcospa.net:SipClientTcp-36:B4FFFB70:SipXProxy:"SipClient[SipClientTcp-36]::run
>> resPoll= 1 revents: fd[0]= 0 fd[1]= 1d"
> I'm not really expert into this specific field but i guess that the
> trouble come from the value of revent (0x1d).
>
> I'm trying to solve the issue inverting the branches order into "if
> else" struct using (fds[1].revents& (POLLERR | POLLHUP)) != 0) as first
> test.
>
> I'll run the test tomorrow (this trouble occurs just into production
> environment, so i need some time to be sure), I hope to get some
> feedback from you.
>
> thanks
> Domenico Chierico
>
>
>
>
> _______________________________________________
> sipx-dev mailing list
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-dev/
>
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
