strange (incorrect) values reported for Counter64 types

[michaelsmit]

Choosing myTotalMemAlloc as an arbitrary Counter64 example.

The correct value (from mysql itself) is 20620520.

The value returned by SNMP walk is MYSQL-SERVER-MIB::myTotalMemAlloc.0 = Counter64: 88564459026513920

That's a bizarre number at first glance, but in hex the two numbers are: 0x13AA4E8 0x13AA4E800000000

Using the log_debug statements that exist and adding a few more, you can see that 20620520 is correctly parsed and passed through all the way to the SNMP handler routine, up to and including this line: $request->setValue(getASNType($global_status{$oidname}{'type'}), "$value"); Right after that, add the line dolog(LOG_DEBUG, $request->getValue()); The output is 88564459026513920

Here is where general knowledge fails me and specific knowledge is required. It appears that NetSNMP::Agent isn't correctly handling the value passed in and is doing some very strange padding with 0s. But there may be some other oddity that is causing the problem.

Experiments with $value->numify() and $value->as_hex() were not successful.

Any ideas would be appreciated.

Linux 2.6.32-318-ec2 #38-Ubuntu SMP Thu Sep 1 18:09:30 UTC 2011 x86_64 GNU/Linux perl v5.10.1 (*) built for x86_64-linux-gnu-thread-multi

[masterzen]

As stated in the read me of this project, you need to run net-snmp version 5.4.3 or better or you will get some issues when fetching 64bits counters.

[michaelsmit]

Thanks - sorry to waste your time just because I can't read. I was using the website post as a Readme and just not paying enough attention. Package manager dependency enforcement has made me lazy and complacent.

Pull request is just a suggestion to prevent people like myself from looking like morons. :)