Thanks to Dave for pointing out this bug.
Setting a watched_spinlock to the wrong type returns wrongValue unless the value matches the actual value in witch case it returns the correct wrongType.
The reason for this is that the watcher helper is an AUTO_NEXT helper and here it sets the result to indicate failure but returns OK since some other handler further down the chain might well wish to indicate some other, more severe error.
Now the question becomes how to solve this in for the general case.
Should netsnmp_request_set_error only allow the error to be set to an error code of higher priority?
Should we demand that every subhandler checks the content of the error status prior to setting it?
Logged In: YES
user_id=88893
Originator: NO
The simplest way to fix this is for the spinlock handler to
check the flag which indicates whether the request has already
been processed, before looking at the new value.
I have a patch to address this, which I'll apply as soon as
the 5.3.x code freeze is lifted.
Logged In: YES
user_id=88893
Originator: NO
Thanks for the bug report!
We've fixed the problem in the 5.2.x, 5.3.x
and 5.4.x code branches and the main development
tree, so it should be fixed in future releases
of the Net-SNMP package.