Unexplained coverage results for snmpset w/invalid values

I’m starting to use lcov (a coverage tool) on one of our projects that has a
net-snmp interface, and I’m getting some false-negatives with the SNMPSET
handler code that I can’t explain.

I _KNOW_ that the test vector script is exercising each read-write
accessible parameter with several boundary conditions (if a parameter can be
set from 0..150 for example, the script tries to set it to -1, 0, 150, and
151, as well as a couple other in-bounds values). The test script is quite
happy with what it’s getting back from our app (the valid #s are accepted,
and the invalid #s result in error responses). 

Here’s the test vector script’s log for a particular parameter: (starts with
an snmpget, and then does the series of sets)

build   22-May-2012 21:01:29   PASS:  Read sysTemperatureAlertHighLim = 68
build   22-May-2012 21:01:29   PASS:  sysTemperatureAlertHighLim  has a
legal value.
build   22-May-2012 21:01:29   PASS:  Set sysTemperatureAlertHighLim to "0"
succeeded as it should have.
build   22-May-2012 21:01:29   PASS:  Set sysTemperatureAlertHighLim to "1"
succeeded as it should have.
build   22-May-2012 21:01:29   PASS:  Set sysTxTemperatureAlertHighLim to
"75" succeeded as it should have.
build   22-May-2012 21:01:29   PASS:  Set sysTxTemperatureAlertHighLim to
"149" succeeded as it should have.
build   22-May-2012 21:01:29   PASS:  Set sysTxTemperatureAlertHighLim to
"150" succeeded as it should have.
build   22-May-2012 21:01:29   PASS:  Set sysTxTemperatureAlertHighLim to
"-1" failed as it should have.
build   22-May-2012 21:01:29   PASS:  Set sysTxTemperatureAlertHighLim to
"151" failed as it should have.

The above Logfile shows that it was set 7 times. The script also resets the
parameter to its original value (which is not logged), so there should be 8
hits to the “MODE_SET_RESERVE1” code for this parameter.

However, when I look at the coverage in the generated HTML, it’s showing
that while the error checking code was hit 6 times, there are 0 hits on the
lines that implement sending out the error messages.

    6857                 :            :         /*
    6858                 :            :          * SET REQUEST
    6859                 :            :          *
    6860                 :            :          * multiple states in the
transaction.  See:
    6861                 :            :          *
http://www.net-snmp.org/tutorial-5/toolkit/mib_module/set-actions.jpg
    6862                 :            :          */
    6863                 :            :         case MODE_SET_RESERVE1:
    6864                 :            :             // First check for for
MIB compliance in this state
    6865                 :          6 :             ret =
netsnmp_check_vb_type_and_size(requests->requestvb, ASN_INTEGER,
sizeof(int)); // match MIB
    6866         [ -  + ]:          6 :             if (ret !=
SNMP_ERR_NOERROR)
    6867                 :            :             {
    6868                 :          0 :                
netsnmp_set_request_error(reqinfo, requests, ret);
    6869                 :            :             }
    6870                 :            :             else
    6871                 :            :             {
    6872                 :          6 :                 SysConfig cfg;
    6873                 :          6 :                
config->getSysConfig(cfg);
    6874                 :          6 :                
cfg.limitsCfg.SysTemperature.alert.high = *requests->requestvb->val.integer;
    6875         [ +  - ]:          6 :                 ret =
config->validateSysConfig(cfg)? SNMP_ERR_NOERROR:SNMP_ERR_WRONGVALUE;
    6876         [ -  + ]:          6 :                 if (ret !=
SNMP_ERR_NOERROR)
    6877                 :            :                 {
    6878                 :          0 :                    
netsnmp_set_request_error(reqinfo, requests, ret);
    6879                 :          6 :                 }
    6880                 :            :             }
    6881                 :          6 :             break;
    6882                 :            : 


Why 6 hits total instead of 8? It’s interesting that I’m giving this 2
invalid cases – it’s almost like those “invalid” cases never came through
here. If that was true, that would also explain the “0” hits on the error
message call. However, when I run this in a debugging session, I can put a
breakpoint on the netsnmp_set_request_error() call and gets hit whenever I
try to set this parameter to an invalid #.

I was curious if the fact that this one source file is an unholy 46K+ lines
long (yikes!) is creating an issue with gcov/lcov/genhtml. I’ve pulled out
one of the snmp parameter handlers into its own file, and didn’t see any
difference in the coverage analysis, however. I’ve had very good luck in the
past with gcov/lcov, so I’ve tended to trust it up to this point.

So, any ideas about how the invalid test cases could be sneaking through the
coverage tool, and yet be triggering the netsnmp_set_request_error() call?
Am I missing something wrt the net-snmp error handler?

Thanks for any clues-
Kevin
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users