I'm playing with a parallel CSV parser and I'm getting SIGSEGV: Illegal storage access. (Attempt to read from nil?) during the reduce operation from the parallel parsers, with the stack trace pointing at the GC code:
.../Development/fastparse/src/fastparsepkg/fparsecsv.nim(281) read_csv_para ==> result.headers = csv.headers
.../.choosenim/toolchains/nim-1.4.0/lib/system/assign.nim(175) genericSeqAssign
.../.choosenim/toolchains/nim-1.4.0/lib/system/assign.nim(139) genericAssign
.../.choosenim/toolchains/nim-1.4.0/lib/system/assign.nim(97) genericAssignAux
.../.choosenim/toolchains/nim-1.4.0/lib/system/gc.nim(447) newSeq
.../.choosenim/toolchains/nim-1.4.0/lib/system/gc.nim(439) newObj
SIGSEGV: Illegal storage access. (Attempt to read from nil?)
Running with valgrind detects many Conditional jump or move depends on uninitialised value(s) or Use of uninitialised value of size 8 errors in GC code too, but at least it completes execution and print the results.
So I decided to use --gc:arc but now the compiler SIGSEGVs while compiling the code! Using --gc:none makes compilation fails on .../.choosenim/toolchains/nim-1.4.0/lib/system/mmdisp.nim(96, 77) Error: undeclared identifier: 'newObj'. Only --gc:boehm gives the expected results though valgring still complains...
There are good odds that's the bug is in my code and I understand that Nim experimental features could have dark corners, but what are the methods to detect if the bug is on my side of the code or on Nim compiler side?