Bad memory management issue with iteration variable warning and dump

[Francesco Casella]

I tried to run models from the PowerGrids library on Windows with the latest nightly build, and most of them caused OMEdit to crash. The problem only takes place on Windows, the Linux version runs fine.

I attach the omeditcommands.mos and openmodelica.stacktrace.OMEdit files corresponding to one such test cases. From what I understand, everything works fine until OMEdit calls the translate() API function, which fails badly. I tried to run the omeditcommands.mos, which also silently fails when executing the translate API function.

The relevant part of the stacktrace seems to be this one

#11 0x00007ffdb22f477f in ntdll!.chkstk () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#12 0x00007ffdb2254bef in ntdll!RtlWalkFrameChain () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#13 0x00007ffdb22f34ee in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#14 0x0000000012c8a2ff in stringAppend () from C:\Program Files\OpenModelica1.14.0-dev-64bit\bin\libOpenModelicaCompiler.dll
No symbol table info available.
#15 0x0000000012b56f3d in omc_DAEDump_dumpCommentAnnotationStr (threadData=threadData@entry=0xb52fb60, _inComment=0xfbc51f63) at C:/dev/OM64bit/OMCompiler/Compiler/FrontEnd/DAEDump.mo:802
#16 0x00000000126923aa in omc_BackendDump_varString (threadData=0xb52fb60, _inVar=0x0) at C:/dev/OM64bit/OMCompiler/Compiler/BackEnd/BackendDump.mo:2492
#17 0x000000001269e05a in omc_BackendDump_printVar (threadData=0xb52fb60, _inVar=<optimized out>) at C:/dev/OM64bit/OMCompiler/Compiler/BackEnd/BackendDump.mo:396
#18 0x000000001269e0f5 in omc_BackendDump_printVars1 (threadData=0xb52fb60, _inVar=0xfe11dc83, _inVarNo=1) at C:/dev/OM64bit/OMCompiler/Compiler/BackEnd/BackendDump.mo:418
#19 0x000000001269e11c in boxptr_BackendDump_printVars1 (threadData=<optimized out>, _inVar=<optimized out>, _inVarNo=<optimized out>) at C:/dev/OM64bit/OMCompiler/Compiler/boot/build/tmp/BackendDump.c:18043
#20 0x0000000012722fd0 in omc_List_fold 
#21 0x000000001269dc0d in omc_BackendDump_printVarList 
#22 0x000000001269dd45 in omc_BackendDump_dumpVarList 
#23 0x00000000125098f1 in omc_SymbolicJacobian_printNonLinIterVarsAndEqs 
#24 0x0000000012509d86 in omc_SymbolicJacobian_checkNonLinDependecies #25 0x0000000012510d20 in omc_SymbolicJacobian_calculateJacobianComponent 
#26 0x0000000012511077 in omc_SymbolicJacobian_calculateJacobiansComponents 

I perfomed a bisection search on the nightly builds, the last nightly that didn't have this issue was ​c6fab8d, while the next one ​f809ccf had it. Hence, there is something wrong with one of these commits:

• ​85d9636 by @AnHeuermann
• ​4697192 by @adeas31
• ​f809ccf by @adeas31

I'd say all the avaliable evidence points to the first one, including the fact that a memory management issue is consistent with the fact that omc fails on Windows but not on Linux.

@AnHeuermann, can you please have a look at this ASAP and fix it on both master and 1.14.0 maintenance?

Thanks!

[Andreas Heuermann]

Yes, it looks like ​85d9636 introduced the bug. I could reproduce the bug and am working on it right now.

[Andreas Heuermann]

See PR ​507 for a fix.

The problem was that some Jacobian variables are missing structural annotations and the dump function DAEDump.dumpAnnotationStr was not robust enough.
Added an else case for missing annotation, so return string is not uninitialized any more.

I think on Linux everything is initialized with zeroes (or in this case an empty string?) and on Windows it's not. So that's why the problem was Windows exclusive.

[Francesco Casella]

Thank you @AnHeuermann. Problem solved :)