On Mon, Jan 5, 2009 at 2:54 PM, Bill Fenner fenner@fenron.com wrote:
==19549== Address 0x4255a58 is 16 bytes inside a block of size 44 free'd ==19549== at 0x402390A: free (vg_replace_malloc.c:323) ==19549== by 0x4038C31: smiFree (util.c:133) ==19549== by 0x4034A97: loadModule (data.c:5308)
So, this is freeing the parser.pendingNodePtr, which is meant to be a temporary root node for forward references to hang from. The problem appears to be that this node actually also becomes the node for the MODULE-IDENTITY, if that is { mib-2 XXX }. A probably-related problem is that the MODULE-IDENTITY doesn't get traversed by smiGetNextNode -- given this module:
BOGO-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2 FROM SNMPv2-SMI;
bogoMib MODULE-IDENTITY LAST-UPDATED "200901050000Z" ORGANIZATION "Bogo" CONTACT-INFO "BOGO" DESCRIPTION "Bogo" ::= { mib-2 XXX }
bogo OBJECT IDENTIFIER ::= { bogoMib 1 }
END
"smidump -f identifiers" only lists bogo:
# BOGO-MIB list of identifiers (generated by smidump 0.4.8)
# WARNING: this output may be incorrect due to significant parse errors
BOGO-MIB bogo node 0.1
If I change the bogoMib definition from { mib-2 XXX } to { 0 }, I get the more desirable output:
# BOGO-MIB list of identifiers (generated by smidump 0.4.8)
BOGO-MIB bogoMib node 0 BOGO-MIB bogo node 0.1
and the python output is fine.
So, is this enough to go on: given the above module as input, I'd like bogoMib to get registered as { 0 }?
Thanks, Bill