Bug 163517 - Create-DataSet Table Index Error
Summary: Create-DataSet Table Index Error
Alias: None
Product: Fedora
Classification: Fedora
Component: net-snmp
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Radek Vokál
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-18 14:34 UTC by W Raul S
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-12-05 07:21:56 UTC
Type: ---

Attachments (Terms of Use)
Test SubAgent Application (4.05 KB, application/x-gzip)
2005-07-20 12:48 UTC, W Raul S
no flags Details

Description W Raul S 2005-07-18 14:34:45 UTC
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):

How reproducible:

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

Comment 1 Radek Vokál 2005-07-20 08:55:53 UTC
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.  

Comment 2 W Raul S 2005-07-20 12:48:28 UTC
Created attachment 116973 [details]
Test SubAgent Application

Comment 3 W Raul S 2005-07-20 12:49:29 UTC
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.

Comment 4 Radek Vokál 2005-11-01 13:43:31 UTC
Can you please retest your problem against latest rawhide version?

Comment 5 Radek Vokál 2005-11-29 10:23:10 UTC
I've tested your issue and it still appears to be broken.

Comment 6 Radek Vokál 2005-12-05 07:21:56 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.