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

[Jochen Katz]

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.

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


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

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

Regards,
  Jochen