I have managed to structure fmusdk code using templates. But now it fails when I compile it using --gc:arc. It fails in the first line of the first function being called.
$ make
...
/home/jose/src/fmi.nim/src/modelinstance.nim(79) fmi2Instantiate
/home/jose/.choosenim/toolchains/nim-1.4.2/lib/system/arc.nim(63) nimIncRef
SIGSEGV: Illegal storage access. (Attempt to read from nil?)
How can I investigate the source of the problem?
I am using a template (with {.dirty.}) to structure the code. How could that affect?
I assume your program crashes when you run it, not that the compiler crashes during compile?
For this case you may try to compile with --gc:arc -d:useMalloc and run your executable with valgrind, that may give you some information. Or you may use a debugger like gdb, but I never did that.
works when being run without --gc:arc
I think for recent Nim ARC is nearly free of bugs now.
So it should crash with default GC after a while, but when you do not allocate much GC memory, the GC may become active late. Have you called GC_fullcollect() with default GC to force collection? You should!
I struggle with memory management (I come from python).
I don't know where to use GC_fullcollect().
I run valgrind on it. Basically, I am creating a library which is within the .fmu file, so I use a second program to execute it. I am getting this:
$ valgrind --tool=memcheck fmusdk-master/fmu20/bin/fmusim_me prueba.fmu 10 0.1
==22881== Memcheck, a memory error detector
==22881== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==22881== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==22881== Command: fmusdk-master/fmu20/bin/fmusim_me prueba.fmu 10 0.1
==22881==
cmd='unzip -o -d fmuTmphCyIRu/ "prueba.fmu" > /dev/null'
fmiModelDescription
fmiVersion=2.0
modelName=inc
ModelExchange
modelIdentifier=inc
dllPath = fmuTmphCyIRu/binaries/linux64/inc.so
FMU Simulator: run 'prueba.fmu' from t=0..10 with step size h=0.1, loggingOn=0, csv separator=',' log categories={ }
==22881== Conditional jump or move depends on uninitialised value(s)
==22881== at 0x486DD2C: eqcopy___59a0n0aMB9aaLvjoB7LISvOg (in /home/jose/src/fmi.nim/src/fmuTmphCyIRu/binaries/linux64/inc.so)
==22881== by 0x486E28D: fmi2Instantiate (in /home/jose/src/fmi.nim/src/fmuTmphCyIRu/binaries/linux64/inc.so)
==22881== by 0x10B703: simulate (main.c:74)
==22881== by 0x10C489: main (main.c:272)
==22881==
==22881== Use of uninitialised value of size 8
==22881== at 0x486DB55: nimIncRef (in /home/jose/src/fmi.nim/src/fmuTmphCyIRu/binaries/linux64/inc.so)
==22881== by 0x486DD3D: eqcopy___59a0n0aMB9aaLvjoB7LISvOg (in /home/jose/src/fmi.nim/src/fmuTmphCyIRu/binaries/linux64/inc.so)
==22881== by 0x486E28D: fmi2Instantiate (in /home/jose/src/fmi.nim/src/fmuTmphCyIRu/binaries/linux64/inc.so)
==22881== by 0x10B703: simulate (main.c:74)
==22881== by 0x10C489: main (main.c:272)
==22881==
==22881== Use of uninitialised value of size 8
==22881== at 0x486DB8B: nimIncRef (in /home/jose/src/fmi.nim/src/fmuTmphCyIRu/binaries/linux64/inc.so)
==22881== by 0x486DD3D: eqcopy___59a0n0aMB9aaLvjoB7LISvOg (in /home/jose/src/fmi.nim/src/fmuTmphCyIRu/binaries/linux64/inc.so)
==22881== by 0x486E28D: fmi2Instantiate (in /home/jose/src/fmi.nim/src/fmuTmphCyIRu/binaries/linux64/inc.so)
==22881== by 0x10B703: simulate (main.c:74)
==22881== by 0x10C489: main (main.c:272)
==22881==
Traceback (most recent call last)
/home/jose/src/fmi.nim/src/modelinstance.nim(81) fmi2Instantiate
/home/jose/.choosenim/toolchains/nim-1.4.2/lib/system/arc.nim(63) nimIncRef
SIGSEGV: Illegal storage access. (Attempt to read from nil?)
==22881==
==22881== HEAP SUMMARY:
==22881== in use at exit: 4,682 bytes in 74 blocks
==22881== total heap usage: 324 allocs, 250 frees, 213,860 bytes allocated
==22881==
==22881== LEAK SUMMARY:
==22881== definitely lost: 0 bytes in 0 blocks
==22881== indirectly lost: 0 bytes in 0 blocks
==22881== possibly lost: 0 bytes in 0 blocks
==22881== still reachable: 4,682 bytes in 74 blocks
==22881== suppressed: 0 bytes in 0 blocks
==22881== Rerun with --leak-check=full to see details of leaked memory
==22881==
==22881== Use --track-origins=yes to see where uninitialised values come from
==22881== For lists of detected and suppressed errors, rerun with: -s
==22881== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
The line 79 looks suspicious to me - you have "ptr fmi2CallbackFunctions" and you cast it to "fmi2CallbackFunctions", can you try doing
let f = functions[]
instead?
And do you have an account on Nim Gitter/Discord/IRC? It's easier to solve issues like these in real time chats
@Yardiniko it fails with and without --gc:arc when doing so. When ARC is not used:
Traceback (most recent call last)
/home/jose/src/fmi.nim/src/modelinstance.nim(165) fmi2Instantiate
/home/jose/src/fmi.nim/src/definitions.nim(83) $
...
/home/jose/src/fmi.nim/src/definitions.nim(83) $
(1874 calls omitted) ...
/home/jose/src/fmi.nim/src/definitions.nim(83) $
....
/home/jose/src/fmi.nim/src/definitions.nim $
Error: call depth limit reached in a debug build (2000 function calls). You can change it with -d:nimCallDepthLimit=<int> but really try to avoid deep recursions instead.
delete your `$`(a:fmi2String) proc or, better, define your fmi2 types as:
type
fmi2String = distinct cstring
proc `$`(s:fmi2String):string {.borrow.}
@shirleyquirk I don't understand it. But it solved some issues with printing things from comp.
@Yardiniko, I don't really feel "under control" of what I'm doing. But with ptr failed, while with ref worked.
Thanks a lot.
The problem is your type fmi2String is a type alias, a synonym for cstring, and can be used interchangeably. So your proc
proc `$`(f:fmi2String): string = $f.cstring
proc `$`(f:cstring): string = $f