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

[John McCaskey]

Hi Jochen,

Thanks again for your continused responses, they are very helpful to me.

On 3/14/06, Jochen Katz <katz at agentpp.com> wrote:
>
> Hi John,
>
> >> 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 :)
>
> if you find the solution please post it (like you suggested) here for
> all others.


I haven't had a chance to work on it much more, but I will be sure to do so
if/when I find a resolution.

>> 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?
>
> Only one thing is not correct: The engine_id is the id of the snmp
> entity (the agent) you want to contact. Any SNMPv3 agent has a unique
> engine id. One way to get it is:
> - Send a request to the agent with an empty user name
> - snmp++ does automatic engine id discovery
> - you get a _local_ error that the user is not known to the USM
> - Get the engine_id through v3MP::get_from_engine_id_table()
> - Now you can add the user for the target


Ahh... I was messing with this for quite a while trying to understand how
the engine id auto-discovery worked.  I think having to go through that
process will present the same type of thread safety issues that I already
have as the auto-discovery requests would have to be serialized I think...

>>  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.
>
> At least they don't cause problems. But as I saw (see other mail from
> today) it does not help if a user is deleted while a message of this
> user is processed. Adding new localized users is safe.
>
> > Ok, so the other thought I've had is can I just create a new v3MP object
> for
> > each thread?
>
> No, v3MP is a singleton global object. Maybe this can be changed for a
> later release, as others have requested this feature already.


Yes, I figured that out rather quickly once I tried to  create multiple
instances.  I've actually modified the codebase to make the v3MP object not
a singleton and instead all of the Snmp:Snmp(..) constructors now take it as
an argument and all code that needs it passes it around or uses the member
pointer inside the Snmp session object.  I'm testing this out and it seems
like it is going to be the ideal fix for my scenario.  Once I've done some
testing of it I'd be more than happy to submit the patch for my changes back
to you if you are interested in including such a change in the mainline
releases.  The only issue I see is that I think a couple of my changes break
compiling without v3 support, but I should be able to work that out fairly
easily.

> 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...
>
> The thing that will happen is: all threads will use the v3MP object that
> was created at last. Some classes just use v3MP::I to access the
> v3mp/USM as they don't have a member pointer.
>
> A complete thread safe USM should be available within the next days.


Excellent...

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