From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4 Description of problem: Using net-snmp 5.2.1-12 ( redhat release 12 for fc3 ), I've found that a create-dataset table ( created and updated through the dataset methods ) returns the wrong index to a row if there is more than one row in the table. This was checked by adding several rows to a table, and then from the programmer's defined request handler, each row was examined ( where each row was extracted from each request ). Each row had the index of another row. The incorrect index was actually the index of the row added before it. My example application runs as a subagent using the example subagent code found on the net-snmp site. The table is defined with each row having 3 columns: string index, U64 value, U64 value. My example application creates rows with corresponding indexes "1","2","3","4' and reports the address of the row created for each index: AddRow():: created row with index "1" at 0x8b40088 AddRow():: created row with index "2" at 0x8b400c8 AddRow():: created row with index "3" at 0x8b40188 AddRow():: created row with index "4" at 0x8b40248 The programmer defined handler extracts the row from each request and reports the address of the row and the row's corresponding index: Examining row with index "1" at 0x8b400c8 Examining row with index "2" at 0x8b40188 Examining row with index "3" at 0x8b40248 Examining row with index "4" at 0x8b40088 You can see that the rows have shifted by one row when reported with the indexes in ascending order ( and order of addition ). Version-Release number of selected component (if applicable): net-snmp-5.2.1-12 How reproducible: Always Steps to Reproduce: 1. Create a mib table with mib2c using create-dataset.conf 2. Add at least two rows using: netsnmp_table_dataset_add_row(table_set,row); 3. Print out memory address of each row of each row request in table handler Or 3. Update all rows with the value 1, except row "2' with 2. 3. Query the mib table. Actual Results: SNMP table: RM-MIB::RmReportingTable index RmValue RmValueTimeStamp "1" 1 1 "2" 1 1 "3" 2 2 "4" 1 1 Expected Results: SNMP table: RM-MIB::RmReportingTable index RmValue RmValueTimeStamp "1" 1 1 "2" 2 2 "3" 1 1 "4" 1 1 Additional info:
Can I get your test application. I wasn't very succesful reproducing this issue. Also if I can get the table conf file, it would be helpful.
Created attachment 116973 [details] Test SubAgent Application
The test case has been included. The case runs as a subgent, and includes its own Mib definition. You may want to add the build directory to $LD_LIBRARY_PATH for the make provided.
Can you please retest your problem against latest rawhide version?
I've tested your issue and it still appears to be broken.
Here's a comment from one of net-snmp developers explaining why the above issue is not a bug. Comment By: Robert Story (rstory) Date: 2005-12-04 09:57 This is not a bug, but rather confusion on the part of the programmer. The index(s) in the table request structure are exactly that - the index(s) from the incoming request. For a get-next request, the requested index(s) will *never* be the same as the row used to satisfy a request, by the very definition of how get-next works. The data-set api and structures should be used to determine the index information for the row being processed in the handler.