[AGENT++] Crash in multi-threaded SNMP++ use (usm_v3.cpp:1262)

Jochen Katz katz at agentpp.com
Mon Mar 13 23:04:17 CET 2006


Hi John,

> Ok, that makes sense as a work around.  The issue I have now is related to
> my other email this morning about the unresolved externals which is popping
> up again when trying to use the Snmp::v3Lock object.  That's perhaps a
> problem with my build environment through and I'll continue to work on that.

it seems to hit any static symbol within a class. As others don't have
this problem, I would also think that some settings are inconsistent
between lib and application. A temporary switch over to a static lib
could help...

> What I'm doing is polling a large number of individual devices every 5
> minutes, some of the devices may use the same username, but have different
> passwords or other authentication settings.  So what I'm doing right now is
> always adding the user when one of my worker threads starts on a new device.
> Is there a potential thread safety issue if in thread 1 I add a user say
> 'userWithAuth', setup an Snmp object utilizing the UTarget, then before
> finishing use of that Snmp session a context switch occurs to thread 2 which
> then adds a new user with the same name, but a different password?

The current no thread safe add_user function is in this case not the
only issue. If you add a user jkatz using the function you wrote (in
order to be able to use automatic engine id discovery) the previous
entry of jkatz will be removed/overwritten. So the following can happen:
Thread A and B
A: add user jkatz with password abc
A: send request to target host1
B: add user jkatz with password ABC
A: Response from target host1 cannot be docoded/authenticated because of
wrong passwords
A: send retry to target host1 created with password ABC
A: receive report because of wrong passwords

If you use the add_usm_user() function that takes the engine_id as
argument, you can create a localized entry for each target. This will
work for sending requests and receiving traps, but not for informs.

Regards,
  Jochen





More information about the AGENTPP mailing list