Libsmi February 2011

libsmi@ibr.cs.tu-bs.de

2 participants
3 discussions

Segfault when parsing invalid MIB
by Vincent Bernat 18 Jun '11

18 Jun '11

Hi! On my computer, smilint RMON2-MIB leads to a segfault because, I think, the rmon symbol is not known because of a missing MIB which leads to an incorrect tokenRing symbol. For example, with smiquery: MibNode: TOKEN-RING-RMON-MIB::tokenRing OID: 32395664.0 Declaration: <value-assignment> NodeKind: node I think that the bogus OID is related to the segfault which happens in checkObjects in the loop that should find the parent node which follows an invalid pointer. I have looked around the segfault but every data is corrupted in the core file. Even modulePtr is not correct at all. I have taken this very small MIB : INVALID-MIB DEFINITIONS ::= BEGIN IMPORTS rmon FROM NORFC-MIB; tokenRing OBJECT IDENTIFIER ::= { rmon 10 } END rmon is not solvable and tokenRing is not solvable too. This does not lead to a segfault, but I get bogus OID : Module: INVALID-MIB MibNode: INVALID-MIB::tokenRing OID: 23465424.0 Declaration: <value-assignment> NodeKind: node I have followed the parser step by step (smiparse()). At the exit of this function, parser.modulePtr is correct. The first object is rmon with OID 0 and the second object is tokenRing with OID 0.10. However, after freeNodeTree(), the second object OID becomes 0.0. I did not see any other change. If I comment freeNodeTree() and smiFree() and try again smiquery, I get: Module: INVALID-MIB MibNode: INVALID-MIB::tokenRing OID: 0.10 ParentNode: INVALID-MIB::rmon Declaration: <value-assignment> NodeKind: node Which seems correct. On the real MIB, I get: Module: RFC1155-SMI Module: TOKEN-RING-RMON-MIB MibNode: TOKEN-RING-RMON-MIB::tokenRing OID: 0.10 ParentNode: TOKEN-RING-RMON-MIB::rmon Declaration: <value-assignment> NodeKind: node Which is fine too. However, smilint still segfaults. I have tried to comment other occurrences of the same pattern with no luck. I am not sure to grasp the structures used by the parser but I believe that when there is no way to link a part of the tree, it is freed. Maybe, those nodes should be attached to some fake element in parser-smi.y instead of setting parentPtr to NULL? I have tried to attach them to modulePtr->firstObjectPtr without any luck. Maybe someone can point me in the right direction to get this right? -- GARLIC GUM IS NOT FUNNY GARLIC GUM IS NOT FUNNY GARLIC GUM IS NOT FUNNY -+- Bart Simpson on chalkboard in episode 7G13

1 2

libsmi/smidump 0.4.8 problem: SYSAPPL-MIB::sysApplPastRunMaxRows SYNTAX Upper Bound
by Jens Engel 18 Mar '11

18 Mar '11

smidump 0.4.8 (up to rev13631 and maybe never) have a problem with the following SMI construct: -- FROM libsmi distributed SYSAPPL-MIB: sysApplPastRunMaxRows OBJECT-TYPE SYNTAX Unsigned32 (0..'ffffffff'h) ... NOTE: 0xFFFFFFFF = 2^32-1 = 4 294 967 295 when you try to convert the provided MIB via: smidump --format=smiv2 SYSAPPL-MIB ... you get the following output for libsmi 0.4.7 and 0.4.8. NOTE: Upper syntax bound is wrong in both cases. === modified file 'IETF/mibs/SYSAPPL-MIB.mib' --- IETF/mibs/SYSAPPL-MIB.mib 2009-03-28 19:03:48 +0000 +++ IETF/mibs/SYSAPPL-MIB.mib 2009-05-04 16:57:29 +0000 @@ -1038,7 +1038,7 @@ ::= { sysApplElmtPastRunEntry 11 } sysApplPastRunMaxRows OBJECT-TYPE - SYNTAX Unsigned32 (0..1134880) -- smidump 0.4.7 output + SYNTAX Unsigned32 (0..1134864) -- smidump 0.4.8 rev13631 (post-release) NOTE: Output of SYNTAX upper bound varies. WEIRD: The conversion to format=python leads to the correct result. Without looking at the source code, I assume that the hex-string to integer conversion has a problem. Ciao, Jens Engel Jens Engel mailto:jens_engel@t-online.de mailto:jens.engel

2 1

memory leaks in smi 0.4.8
by Fort, Andrew 28 Feb '11

28 Feb '11

> I have detected a couple of memory leaks (using Visual Leak Detector) in a > project where I parse a MIB with 4 imported MIBs. > > One (44 bytes) seems to be associated with 'parser.pendingNodePtr' > allocated > in smiInitData. (adding smiFree(parser.pendingNodePtr); at the end of the > function removes this leak). > > The 2nd leak (36 bytes) originates in smiLoadModule used to handle the MIB > parsing. The call stack returned was: > Call Stack: > c:\projects\hf sdr\msvc\smi-0.4.8\<stdout> (14160): smirealloc > c:\projects\hf sdr\msvc\smi-0.4.8\<stdout> (13871): > smiensure_buffer_stack > c:\projects\hf sdr\msvc\smi-0.4.8\<stdout> (13647): > smi_switch_to_buffer > c:\projects\hf sdr\msvc\smi-0.4.8\scanner-smi.l (82): > smiEnterLexRecursion > c:\projects\hf sdr\smi-0.4.8\lib\data.c (4733): loadModule > c:\projects\hf sdr\msvc\smi-0.4.8\parser-smi.y (1755): smiparse > c:\projects\hf sdr\smi-0.4.8\lib\data.c (4740): loadModule > > Any insights welcome. > > Regards, > > Andrew Fort. >

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Libsmi February 2011