[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