
Hi
I've been trying to build libsmi trunk for x86_64-w64-mingw32 and I've encountered a problem. I don't know whether the MIB I'm trying to load has some invalidity, though it's a CISCO MIB and smilint accepts it. Presumably I have done something wrong elsewhere and will look into that separately.
Regardless, the particular segfault I received led me to this code (lib/parser-smi.y:2420), which seems strange:
if (!($11)) smiPrintError(thisParserPtr, ERR_INTERNAL); /* * Otherwise, we have to allocate a * new Type struct, inherited from $10. */ $$ = duplicateType($11, 0, thisParserPtr);
duplicateType (lib/smi-data.c:2404) unconditionally dereferences its first parameter so, since $11 is invalid in this block, the call to duplicateType is broken.
What is this code supposed to be instead?
Best regards Tom

On 11/04/2015 17:51, Tomalak Geret'kal wrote:
Hi
I've been trying to build libsmi trunk for x86_64-w64-mingw32 and I've encountered a problem. I don't know whether the MIB I'm trying to load has some invalidity, though it's a CISCO MIB and smilint accepts it. Presumably I have done something wrong elsewhere and will look into that separately.
Regardless, the particular segfault I received led me to this code (lib/parser-smi.y:2420), which seems strange:
if (!($11)) smiPrintError(thisParserPtr,
ERR_INTERNAL); /* * Otherwise, we have to allocate a * new Type struct, inherited from $10. */ $$ = duplicateType($11, 0, thisParserPtr);
duplicateType (lib/smi-data.c:2404) unconditionally dereferences its first parameter so, since $11 is invalid in this block, the call to duplicateType is broken.
What is this code supposed to be instead?
Best regards Tom
Could it be as simple as
- $$ = duplicateType($11, 0, thisParserPtr); + $$ = duplicateType($10, 0, thisParserPtr);
?
If so, do I need to make the same change in lib/parser-smi.c? Or will that be done for me during the build?
Best regards Tom

On Sat, Apr 11, 2015 at 05:51:18PM +0100, Tomalak Geret'kal wrote:
Hi
I've been trying to build libsmi trunk for x86_64-w64-mingw32 and I've encountered a problem. I don't know whether the MIB I'm trying to load has some invalidity, though it's a CISCO MIB and smilint accepts it. Presumably I have done something wrong elsewhere and will look into that separately.
Regardless, the particular segfault I received led me to this code (lib/parser-smi.y:2420), which seems strange:
if (!($11)) smiPrintError(thisParserPtr, ERR_INTERNAL); /* * Otherwise, we have to allocate a * new Type struct, inherited from $10. */ $$ = duplicateType($11, 0, thisParserPtr);
duplicateType (lib/smi-data.c:2404) unconditionally dereferences its first parameter so, since $11 is invalid in this block, the call to duplicateType is broken.
Yep, this looks broken.
What is this code supposed to be instead?
Can you send me (privately) the MIB file that triggers this problem? This might help me to figure out what should be hapening here. This is the only place where the parser - actually the whole libsmi library - throws an internal error...
/js

On 14/04/2015 20:59, Juergen Schoenwaelder wrote:
Can you send me (privately) the MIB file that triggers this problem? This might help me to figure out what should be hapening here. This is the only place where the parser
- actually the whole libsmi library - throws an internal
error... /js
Hi Jurgen,
If I set my MIB search path such that libsmi can /only/ see http://www.cisco.com/iam/PGW_MIBS/932/ctc.my, (and not those packaged with the project), I can pretty reliably get a segfault on launch from my x86_64-w64-mingw32 (GCC 4.9.2) build.
I realise that one wouldn't deliberately do this, but it's quite easy to get MIB search paths wrong so a segfault is an ungraceful failure from that POV!
If you can't reproduce or would like more details please let me know.
:)
Cheers Tom

On Wed, Apr 15, 2015 at 05:32:32PM +0100, Tomalak Geret'kal wrote:
On 14/04/2015 20:59, Juergen Schoenwaelder wrote:
Can you send me (privately) the MIB file that triggers this problem? This might help me to figure out what should be hapening here. This is the only place where the parser
- actually the whole libsmi library - throws an internal
error... /js
Hi Jurgen,
If I set my MIB search path such that libsmi can /only/ see http://www.cisco.com/iam/PGW_MIBS/932/ctc.my, (and not those packaged with the project), I can pretty reliably get a segfault on launch from my x86_64-w64-mingw32 (GCC 4.9.2) build.
I realise that one wouldn't deliberately do this, but it's quite easy to get MIB search paths wrong so a segfault is an ungraceful failure from that POV!
If you can't reproduce or would like more details please let me know.
I can't reproduce this on Linux / MacOS - the only OSes I use.
/js
participants (2)
-
Juergen Schoenwaelder
-
Tomalak Geret'kal