On Thu, Nov 15, 2012 at 8:46 AM, Fulko Hew <fulko....@gmail.com> wrote: > > On Wed, Nov 14, 2012 at 10:41 AM, Fulko Hew <fulko....@gmail.com> wrote: > > > > While testing my app, I think I've discovered an issue... > > > > My app uses AgentX to interact with net-snmp and during the course of > > events it typically performs a large number of the following sequence: > > > > newIndex = IndexAllocate(ANY_INDEX) [of an Integer value] > > Register(OID.newIndex); > > ... > > > > Unregister(OID.index) > > IndexDeallocate(OID, index) > > ... > > > > When the number of rows (sequence of allocate/register/unregister/deallocate) > > is small (less than 255 entries) it works fine, but as soon as I add a 256th > > entry for my table (that I've registered), when I go to Unregister (them all), > > one of them will fail with an indexNotAllocated error response. > > I have investigate this further, I don't know which end has the problem, > but I _have_ located the issue. Its not an issue of the number of allocations, > but 'selective index usage'. I believe if you will see the problem with this > simplified test: > > IndexAllocate(1); > IndexAllocate(256); > > IndexDeallocate(256); > > > The Background: > Net-SNMP records its index allocations as an ordered > linked list. When you deallocate an index, it scans > the list until it either finds your entry, or > (in theory) finds an entry _beyond_ your request. > > The trouble is, that (at least in the case of INTEGER indexes on > a little-endian machine) is that the test for 'beyond your entry' > isn't correct. ie. 'did I match the entry I'm looking for, or have > I passed it.' > > I don't know if this is a generic routine (for all types of indexes) > or if its a little/big endian issue, but the routine unregister_index() > in agent/agent_index.c uses memcmp() as its check technique. > > On a typical scenario (looking for index '216'), the comparisons > look like this: > > ... > d8 00 00 00 d6 00 00 00 d8 is > d6, so keep scanning > d8 00 00 00 d7 00 00 00 d8 is > d7, so keep scanning > d8 00 00 00 d8 00 00 00 d8 is <= d8, so exit the scan > > Given my simplified two entry test (1, 256) above, the linked > list to traverse looks like this: > > 01 00 00 00 > 00 01 00 00 > > so the comparison (when deallocating index '256') goes like this: > > memcmp(00 01 00 00 01 00 00 00) > ^^ ^^ > memcmp will test the first two bytes of the sequences > to find that 00 is <= 01 so it exits the scan prematurely! > > It should be scanning the most significant octet first! > > So... is the problem: > > - the list (with INTEGERS) was built in little-endian mode? > (I happen to be running on Intel) > - the list (with INTEGERS) is not endian-ness independent? > - the list scanner assumed little-endian-ess (INTEGERS)? > - the list scanner assumed a STRING index and didn't account correctly > for INTEGER indexes (in a known or unknown) endianess storage format? > > Since I don't know what the original intent was > (for the allocator, and for the various index types) > I'm reluctant to develop and submit a fix for this problem. > > Can someone with a little more background shed some light?
After reviewing the existing code, I see in the file 'agent/agent_index.c' the register_index() routine performs three different actions (for integers, strings and OIDs) to determine prior existence of an index. The attached patch duplicates that relevant bit of code into the unregister_index() routine also. I have tested the patch (for INTEGER style indexes only) against my examples above and it resolves the problem. I have submitted an entry into the patch tracker for this item: https://sourceforge.net/p/net-snmp/patches/1240/ Fulko
patch
Description: Binary data
------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
