[Xorp-hackers] XORP IPC mechanism is stressed by data plane traffic

[Pavlin Radoslavov]

> >> BTW
> >> I encounter the following problem during stress testing, because I'm 
> >> using ported XORP source code, and they are NOT based on the latest CVS HEAD.
> >> I could not ensure you can reproduce the problem, but just in case anybody 
> >> have interest to track it...
> >> 
> >>  * In a high volume data traffic enviroment
> >>  * without the tuning above
> >>  * try to send XORP component XRL commands through call_xrl
> >>  * call_xrl's XrlPFSTCPSender dies with EWOULDBLOCK/ENOBUFS...
> >> 
> >> task calling call_xrl core dumps, and the stack looks something
> >> like
> >
> >Is this with the original XORP call_xrl binary called by a script
> >(or exec()-ed), or this is in the in-process code that has been
> >derived from call_xrl?
> 
> in-process code derived from call_xrl
> 
> 
> >Also, could you tell the particular reason for the coredump (e.g.,
> >invalid pointer, etc), because I cannot decode the log below.
> >
> 
> I don't catch the reason (that's why I paste the stack information)
> But it is triggered by XrlPFSTCPSender::die, and from the stack 
> information it seems that response_handler doesn't return properly.
> Again, I'm not sure we can reproduce it on XORP CVS HEAD version.
> Anyway, can we move this to bugzilla and track it there?

Given that the coredump happens in some non-trivially modified code,
we cannot add it to bugzilla without any source code that
demonstrates the problem.

I was looking into the particular segment of the
XrlPFSTCPSender::die() method (that you have commented), and
that particular piece of code tries to do something clever to invoke
the pending callbacks in case of error. If that code is
commented-out, some callbacks may not be invoked as appropriate.

Thanks,
Pavlin