ok, further customer findings On Tue, 2005-08-30 at 12:08 -0400, Robert Story wrote: > On Tue, 30 Aug 2005 15:54:32 +0200 Radek wrote: > RV> Now my understanding, which may well be incorrect, is that the callback > RV> function is used to handle a response to the trap? Is that correct? If > RV> so, why do we pass in a NULL pointer for the callback function? > > First of all, traps do not get responses. Informs do, but traps do not. > Second, in the absence of user supplied callbacks, there are defaults. >
Apologies for my ignorance over terminology. The code (previously
referenced) suggests those defaults are NULL pointers.
>
> RV> I know we expect a response because:
> RV>
> RV> a. I traced that with gdb
> RV>
> RV> We enter code:
> RV>
> RV> /*
> RV> * Add to pending requests list if we expect a response.
> RV> */
> RV> if (pdu->flags & UCD_MSG_FLAG_EXPECT_RESPONSE) {
>
> In that case, you must be sending an inform, and not a trap.
>
Indeed!
> RV> b. I traced it with strace
> RV>
> RV> An strace of the app shows us doing a send(2) but no recv(2)
> RV>
> RV> An strace of snmpd shows us doing a recv(2) and then a send(2)
> RV>
> RV>
> RV> An strace shows that we eventually hang, I have not checked this with
> RV> crash(1) but I suspect it is because we are not draining the socket of the
> RV> snmpd responses.
>
> So what is consuming the resources, and what hangs? The app, or snmpd? Is the
> app independent of snmpd, or is it a subagent?
The app consumes the memory, more specifically, within the snmp libs. It
is also the app that hangs.
> RV> o we continue to hold memory because we never employ a callback to
> RV> consume the response, which would also result in a freeing of
> RV> associated resources
>
> This doesn't make sense, because if it is an inform, the lack of a response
> should cause resends, and then eventually a timeout, which should release
> resources.
I'm only relaying what I see via strace, empirical observations.
> RV> o we eventually hang because we are not handling the response and
> RV> therefore consume resources associated with the socket
>
> Are you using tcp, or udp? The default is udp, and a full buffer should cause
> dropped packets, not a hang. Tcp or domain sockets, on the other hand, could
> hang on a full buffer.
It is all running on the localhost and appears to be using local domain
sockets.
Also customer provides a test case (see attached file), in which he sees
using memprofiler that every step allocates 588bytes of memory which are
never freed and which are leading to application resource shortage
problems.
Radek
--
Radek Vokál <[EMAIL PROTECTED]>
src-example.tar
Description: Unix tar archive
signature.asc
Description: This is a digitally signed message part
