memory leaks in snmp++

[Henning Eggers]

Hi Jochen!

> > [very good report and fix for v3MP memory leak]
Thanks for the flowers ;-)

Here is another one ...

The method "EventListHolder::SNMPProcessEvents()" calls the socket function
"select()" with a time-out "fd_timeout" to determine if any data arrived on
the socket and to block the thread while all is calm. The value of
"fd_timeout" is calculated with "CEventList::GetNextTimeout" and
"msec::GetDelta()" to find the next expected timeout in the event list. This
way "select()" won't block any longer than nescessary. So far, so good.
If there are currently no events in the list, "GetNextTimeout" returns
"Infinite" which makes "GetDelta" return the "MAX_ALARM" value. This value
is currently defined to "1000000000L", over 37 years, which really is
infinite in this context. What happens, if the application launces a new GET
request within these 37 years, which receives no response and should be
timed out? The consequence is that the message won't get removed from the
event list until 37 years have passed - virtually never. It gets worse if
the application keeps trying to poll a value on a dead agent and never gets
a response: the event list keeps building up and events are never timed outAdmittedly, this situation only occurs if the whole network is dead and the
event list is empty at some point. But it happened to me ;-) Possible
solutions:
1.) Define "MAX_ALARM" to "1L" for msec.cpp, so that the timeout is never
more than 1 second. That's what I did.
2.) Use the "max_block_seconds" parameter of
"EventListHolder::SNMPProcessEvents()". This can only be done effectively by
adding this parameter to "EventListHolder::SNMPMainLoop()" which is then
passed to "EventListHolder::SNMPProcessEvents()". This would look like this:

void EventListHolder::SNMPMainLoop(const int max_block_seconds /* =  0 */ )
{
  do {
    SNMPProcessEvents( max_block_seconds );
  } while (!m_eventList.Done());
}

The question remains if using such an "infinite" value on "select()" is such
a good idea in the first place. I think "select()" should return every now
and then so that any other events may be checked on. Finding a good value
for a time-out here is really a question of performance. Alternatively,
time-out processing could be done in a seperate thread...

Since this problem only occurs in these special cicumstances, it may not be
nescessary to do more about it than suggestion 2.) above. I could live with
that.

Greetings,
Henning