Unhandled Exception in AgentX++ !

[Frank.Fock____t-online.de]

Hello Christel,

I have a few question to better understand the problem:

1. Does the problem occur on every writeable object?
2. Does the subagent crash or the master? (Seems to be
   the subagent)
3. Is the master agent also a AgentX++ agent?
4. If (1) is not true, did you check whether your 
   instrumentation answers the request twice?
5. If (3) is not true, does the master agent sends
   a valid SET request sub-type (COMMIT, CLEANUP, etc.)
   that is expected by the AgentX++ protocol?

You said that Purify shows that the Pdu object is 
garbage, so it has been deleted and reallocated afterwards,
otherwise Purify should have reported an error before. 
Thus, I doubt that the request object is still valid
memory, maybe it just did not get reallocated until the
exception occured.

Maybe with more information I could reproduce the problem
here...

Best regards,
Frank

christel.sohnemann at philips.com schrieb:
> Hello,
> 
> I get an unhandled exception in AgentX++ Layer when 
> sending 2 equal set-requests to the master agent within a 
> very short time (for example 5 
> seconds).
> I debugged the code with "Purify" and I could localize 
> the following Code-Pieces where the behaviour of the 
> AgentX++ seems to be very unstable: 
> 
> first ist:
> 
> int MibLeaf::commit_set_request(Request* req, int ind)
> {
>       // set the value. set is a wrapper for set_value 
> unless 
>       // set is overwritten by subclasses
>       int status = set(req->get_value(ind));
>       if (status != SNMP_ERROR_SUCCESS) {
>             return SNMP_ERROR_COMITFAIL;
>       }
>       // don't send answer until cleanup finished
>       Mib::requestList->done(req->get_transaction_id(),
>                          ind, req->get_value(ind));
> 
>       // notify other classes of change this value
>       notify_change(get_oid(), CHANGE);
>       return SNMP_ERROR_SUCCESS;
> }
> 
> and second is:
> Here I detected remove = 0. Further on, "request" is 
> still valid, but the PDU object is kind of "rubbish". It 
> is a pointer to something like 0x"aeaeaeae". 
> That's where - I guess - my program crashes.
> So my idea is: is it possible, that 2 concurring threads 
> try to delete the same object? 
> 
> void AgentXRequestList::answer(Request* req) 
> TS_SYNCHRONIZED( 
> {
>       // CAUTION: Make a copy of PDU here because when we 
> answer 
>       // the request, the response could be so fast back 
> to our 
>       // master, that the following request could be 
> processed 
>       // before we have finished here. In the case of a 
> COMMIT 
>       // or CLEANUP following a PREPARE_SET this could 
> cause a seg 
>       // fault because the request were are dealy with 
> here is deleted 
>       // by the main thread by calling 
> AgentXRequestList::receive! 
>       //
>       AgentXPdu* pdu = new 
> AgentXPdu(*((AgentXPdu*)req->get_pdu())); 
> 
>       boolean remove = TRUE;
>       // check if we need request for further processing
>       switch (pdu->get_agentx_type()) {
>       case AGENTX_TESTSET_PDU:
>       case AGENTX_COMMITSET_PDU:
>         remove = FALSE;
>         break;
>       }
>       if (remove)
>             requests->remove(req);
>       pdu->set_agentx_type(AGENTX_RESPONSE_PDU);
>       int status = agentx->send(*pdu);
> 
>       if (!remove) {
>         // If we do not get a CLEANUP from the master
>         // we have to remove the pending request by 
> ourselves. 
>         ((AgentXRequest*)req)->get_agentx_pdu()->
> set_timestamp(agentx->compute_timeout(AGENTX_DEFAULT_TIM
>           EOUT)); 
>         ((AgentXRequest*)req)->unlock();
>       }
>       LOG_BEGIN(EVENT_LOG | 4);
>       LOG("RequestListAgentX: request answered 
> (id)(status)(tid)(err)(removed)(sz)"); 
>       LOG(pdu->get_request_id());
>       LOG(status);
>       LOG(pdu->get_transaction_id());
>       LOG(pdu->get_error_status());
>       LOG(remove);
>       LOG(pdu->get_vb_count());
>       LOG_END;
> 
>       delete pdu;
>       if (remove)
>             delete req;
> })
> 
> 
> I am sorry, I cannot send you the complete code I have, 
> as it is just too much and I do not have the time to 
> extract it. 
> Any help from you is more then welcome, as this is really 
> urgent to us and I am sitting in a kind of "locked room 
> (nothing-disturbes-me-environment)" to fix it. 
> 
> Thank you very much in advance.
> 
> Best regards, Christel
> 
> 
> Christel Sohnemann
> Software Development
> Philips Speech Processing Aachen, Zweigniederlassung der 
> Philips GmbH 
> Kackertstr. 10, 52072 Aachen, Germany
> mailTo: christel.sohnemann at philips.com
> Tel:    +49 - (0)241 - 8871 191,    Fax: +49 - (0)241 - 
> 8871 140 
> http://www.speech.philips.com/
> 
> 
>