Bug 452131

From the description I cannot guess what's wrong. Could you please provide
detailed steps, how to reproduce the bug? I think simple perl code, resulting in
the assertion failure, will tell more than the description above. Thanks in advance.

Sorry, hadn't attached fix, but to reproduce:

-You must have some equipment where you can attempt to set some OID.  Without
knowing about your test environment, I can't suggest a reasonable OID, but it
would be something like:
 $session = new SNMP::Session(
                    DestHost => $dst,
                    Version => '3',
                    SecName => $username,
                    AuthProto => 'SHA',
                    AuthPass => $password,
                    PrivProto => 'DES',
                    SecLevel => 'authPriv',
                    UseNumeric => 1,
                    Retries => 2, 
                    Timeout=>1300000,
                    PrivPass => $password);

my $varbind = new SNMP::Varbind([$numericoidhere,0,1,'INTEGER']);
$data = $session->set($varbind);

The output of that is:
Assertion ((svtype)((_svi)->sv_flags & 0xff)) >= SVt_PV failed: file "SNMP.xs",
line 3070 at
/usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/SNMP.pm line 617.


The path I have attached prevents that failure for me.

Created attachment 310031 [details]
Patch to net-snmp that worked for me.

At least in a different setup (Net-SNMP 5.4.2.pre2 with Perl 5.8.8 on i686) I
couldn't reproduce the failure. Do you also see this problem on x86 (32-bit)?

F9 (perl 5.10.0) asserts with today's net-snmp SVN trunk (rev. 17096) both on
x86_64 and i386. It does not assert on F8 (perl 5.8.8) i386.

The old & working perl 5.8.8 defines SvOK as
#define SvOK(sv)                (SvFLAGS(sv) & SVf_OK)

The new perl 5.10 defines it as 
#define SvOK(sv)                ((SvTYPE(sv) == SVt_BIND)               \
                                 ? (SvFLAGS(SvRV(sv)) & SVf_OK)         \
                                 : (SvFLAGS(sv) & SVf_OK))

Question is, why does it influence net-snmp.

Anyway, the reporter complains that SvOK does not work while SvPOK works. IMHO
these two macros should behave consistently.

No, they don't behave the same way. First one returns 1, when there isn't undef
value, the second is checking pointer value. Also as was mentioned in perl bugzilla:
http://rt.perl.org/rt3/Public/Bug/Display.html?id=53244

"SvCUR() is supposed to return the 'length of the string in the SV',
but when SvPOK() is not set, then there is no string in the SV, ..."

So the patch is correct fix and net-snmp should be fixed.

Fixed in rawhide, ver. net-snmp-5.4.1-20. I'll release F9 update when more
bugfixes come.

net-snmp-5.4.1-19.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/net-snmp-5.4.1-19.fc9

net-snmp-5.4.1-19.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

I am using F9 with net-snmp-5.4.1-19.fc9.i386 and perl-5.10.0-68.fc9.i386 and I am still getting the same error reported above on SNMP set:

Assertion ((svtype)((_svi)->sv_flags & 0xff)) >= SVt_PV failed: file "SNMP.xs", line 3070 at /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi/SNMP.pm line 617.

Do you know if the patch made it all the way?

Yes, the patch from comment #3 is in net-snmp-5.4.1-19. Maybe you see different error. Anyway, F9 is not supported anymore, try to reproduce it with newer Fedora.