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?)
Run
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?
