memory leaks in snmp++

Henning Eggers henning.eggers____plath.de
Tue May 6 18:30:23 CEST 2003


Hi Frank,
I was away for a week so I couldn't answer any earlier. Also since Monday I
have been looking more into the problem and actually found a leak.
> Can you reproduce the leak with a simple
> example? What kind of requests are you using
> (GET, GETNEXT, etc.)? What SNMP version?


I forgot to mention that I am developing on Windows XP (hey, it's good money
;-). I am sending out SNMPv3 GET requests.

To make sure it isn't my code, I simply use the snmpNextAsync example and
modified it to send out many async GET requests with looped calls to
EventListHolder::SNMPProcessPendingEvents() in between. For leak detection I
use the built-in functions in Visual Studio (_CrtMemDumpAllObjectsSince
etc.) but at first the Task List was enough to see that the program was
eating memory.

I found out that each message gets added to the v3MP::Cache array which
grows dynamicly. There is a delete_from_cache method in v3MP which is
supposedly called on time-outs but that is only true in
SNMPBlockForResponse(). It never gets called in real asynchronous operationSo the v3MP::Cache array keeps growing and growing with each time-out that
occurs... I added the code from SNMPBlockForResponse() to
CSNMPMessageQueue::DoRetries() and that did the trick. I am not sure,
though, if that is the best place to put it. This should be for you or
Jochen to decide, as I just barely get the hang of how things are working
under the hood of SNMP++. Here is the new code snippet from msgqueue.cpp.
CSNMPMessageQueue needs to be a "friend" to v3MP in order to be able to call
delete_from_cache()

 if (status == SNMP_CLASS_TIMEOUT) {
  unsigned long req_id = msg->GetId();
   // Dequeue the message
    DeleteEntry(req_id);
#ifdef _SNMPv3
  // delete entry in cache
  if (v3MP::I)
    v3MP::I->delete_from_cache(req_id);
  debugprintf(8, "CSNMPMessageQueue, called v3MP::delete_from_cachemp"
   " due to timeout");
#endif

 }

Unfortunately there seem to be some more, although much smaller, leaks. I
will look into that.

Regards,
Henning




More information about the AGENTPP mailing list