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

[John McCaskey]

Hi Jochen,

Sorry to respond again before you even have a chance to reply but I had
another thought, see below...

On 3/13/06, John McCaskey <jmccaskey at gmail.com> wrote:
>
> 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.
>

Ok, so the other thought I've had is can I just create a new v3MP object for
each thread?  The worker threads that do my SNMP polling are all allocated
at system startup and there is a fixed number so I'm not ultra concerned
aboute the overhead of doing this, I'm more concerned about how the
documentation tells me to only do it once and maybe that means there are
some global variables in use that will cause bad things to happen if I have
multiple instances in seperate threads... having the threads completely
independant and not sharing any USM info would be fine with me.

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
> >
>
>