Corrupted node when parsing MIB with { mib-2 XXX } for MODULE-IDENTITY
Hi,
When running smidump on http://mibbinator.org/mibindex/extracted/BGP4V2-MIB-idr-08.txt and outputting in python format, the node after bgp4V2Groups has ASCII text instead of a Node data structure, causing smiGetNextNode() to crash.
1613 nodePtr = nodePtr->nextPtr; $30 = (Node *) 0x57c600 (gdb) x/s $30 0x57c600: "}, # node\n"
This is the last line that was output, I think because this Node was freed and so smiVasprintf is using the same memory area for line buffering, but there were still pointers to it.
I will admit to running with "-k", to ignore the "mib-2 XXX" error in this MIB; this works with -f identifiers but seems to be the killer for -f python/perl/yang.
When the { mib-2 XXX } is replaced by { mib-2 9999 }, the python/ perl/yang outputs succeed.
In my use case (getting python access to the structure of a MIB in an Internet Draft), I need the output to work in this case. This worked some time ago (unfortunately I didn't practice good revision control and don't know exactly which version broke this; I developed the functionality that required this behavior in mid-2007).
Any ideas where to look to find out what is freeing this node? (I tried --enable-dmalloc but the dmalloc linkage didn't work)
Thanks, Bill
On Sun, Jan 04, 2009 at 06:05:00PM -0800, Bill Fenner wrote:
When running smidump on http://mibbinator.org/mibindex/extracted/BGP4V2-MIB-idr-08.txt and outputting in python format, the node after bgp4V2Groups has ASCII text instead of a Node data structure, causing smiGetNextNode() to crash.
Can you please check the head version of the SVN? It seems to work for me now although I am not quite sure why the change fixes this problem.
I also noticed that dump-python generates output like
"reference>" : """RFC 4271, Section 4.2, 'BGP Identifier'.""",
and somehow it looks like "reference>" should really be "reference" (and now I notice that the same happens in dump-perl). Shall this be fixed or does this break scripts?
/js
On Mon, Jan 5, 2009 at 12:50 AM, Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de wrote:
On Sun, Jan 04, 2009 at 06:05:00PM -0800, Bill Fenner wrote:
When running smidump on http://mibbinator.org/mibindex/extracted/BGP4V2-MIB-idr-08.txt and outputting in python format, the node after bgp4V2Groups has ASCII text instead of a Node data structure, causing smiGetNextNode() to crash.
Can you please check the head version of the SVN? It seems to work for me now although I am not quite sure why the change fixes this problem.
I have the same problem still with @12245; same crash in the same location with the same ASCII instead of data structure.
I also noticed that dump-python generates output like
"reference>" : """RFC 4271, Section 4.2, 'BGP Identifier'.""",and somehow it looks like "reference>" should really be "reference" (and now I notice that the same happens in dump-perl). Shall this be fixed or does this break scripts?
I think it should be fixed, and any scripts should get fixed too, but I don't know how many people are using this output in what way. My script doesn't need to be fixed -- right now it would just ignore "reference>" --
object.reference = nodeinfo.get('reference', '')
Bill
On Mon, Jan 05, 2009 at 11:00:23AM -0800, Bill Fenner wrote:
On Mon, Jan 5, 2009 at 12:50 AM, Juergen Schoenwaelder
I also noticed that dump-python generates output like
"reference>" : """RFC 4271, Section 4.2, 'BGP Identifier'.""",and somehow it looks like "reference>" should really be "reference" (and now I notice that the same happens in dump-perl). Shall this be fixed or does this break scripts?
I think it should be fixed, and any scripts should get fixed too, but I don't know how many people are using this output in what way. My script doesn't need to be fixed -- right now it would just ignore "reference>" --
object.reference = nodeinfo.get('reference', '')
I agree - I assume people discovering the bad spelling would have notified us to get this fixed and so I conclude that nobody every discovered this and hence nothing can break by fixing this. Patch committed.
/js
On Sun, Jan 04, 2009 at 06:05:00PM -0800, Bill Fenner wrote:
Any ideas where to look to find out what is freeing this node? (I tried --enable-dmalloc but the dmalloc linkage didn't work)
I fixed the dmalloc linkage so that it works with newer versions of dmalloc. But unfortunately, dmalloc stays silent (but I admit not being a dmalloc expert). Anyway, I have committed the dmalloc linkage fixes.
I went back to revision 7563 (2008-01-01), 6403 (2007-01-01), and 3078 (2006-06-06) and they all show the same problem. If this ever worked, it must have been a long time ago. I guess I will leave this alone for the moment; something is likely overwriting a pointer here and I am not sure how to track this down at the moment...
/js
valgrind to the rescue.
==19549== Invalid read of size 4 ==19549== at 0x403C2D9: smiGetNextNode (smi.c:1611) ==19549== by 0x807118B: fprintNodes (dump-python.c:808) ==19549== by 0x8071C4C: dumpPythonModule (dump-python.c:1057) ==19549== by 0x8071D2A: dumpPython (dump-python.c:1084) ==19549== by 0x804AE2E: main (smidump.c:419) ==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) ==19549== by 0x403AA59: smiLoadModule (smi.c:422) ==19549== by 0x804AD1D: main (smidump.c:399) ==19549== ==19549== Invalid read of size 4 ==19549== at 0x403C2ED: smiGetNextNode (smi.c:1613) ==19549== by 0x807118B: fprintNodes (dump-python.c:808) ==19549== by 0x8071C4C: dumpPythonModule (dump-python.c:1057) ==19549== by 0x8071D2A: dumpPython (dump-python.c:1084) ==19549== by 0x804AE2E: main (smidump.c:419) ==19549== Address 0x4255a5c is 20 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) ==19549== by 0x403AA59: smiLoadModule (smi.c:422) ==19549== by 0x804AD1D: main (smidump.c:399)
I'll dig into this a little more.
Bill
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
participants (2)
-
Bill Fenner -
Juergen Schoenwaelder