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

[John McCaskey]

Hi Jochen,

On 3/13/06, Jochen Katz <katz at agentpp.com> wrote:
>
> 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...


Yeah, its definately some sort of issue with my build environment... I hate
working with Visual Studio.  The linux builds are working fine. I'll take
the issue up with some win32 guru's here.  Thanks for trying to 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


Exactly what I was afraid of...

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.


Ok, so just to be sure, what it sounds like I should do is initialize the
v3MP globally, in each thread then use the get_usm call to get a reference
to its USM object, and then when I do add_usm_user inside of the thread
specify a thread specific engine id (I'm thinking the app name with the tid
appended or such), and then I should never have a conflict with one thread
overwriting/deleting a usm user entry thats in use by another thread (since
my engineID's are unique per thread).  Is that correct?  I'm assuming I
still need the Snmp::v3Lock.lock()/unlock() calls around that code due to
the safety issues in add_usm_user as well.

Thanks again for all your help, I'm really eager to get everything working
as the code for SNMP++ seems to be very clean and easy to use in comparison
to what we have now.

Regards,
>   Jochen
>
>
> _______________________________________________
> AGENTPP mailing list
> AGENTPP at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/agentpp
>