Hey, I just had a pretty weird bug.
I required a queue with a peak function and because I was lazy I just copy pasted the library one and added that one method. I recently had multiple such situations where I needed some simple behaviour like manually walking the tree from the critbit module to do backtracking. Is it really necessary to copy the entire file to insert one or two stars somewhere?
Anyway, I think that doesn't have anything to do with the bug. The queue stores objects which each contain three seq's. It triggers when the add function resizes the queue, but not always. Here is the stack trace:
Traceback (most recent call last)
StrokeQueue.nim(142) LogParser
StrokeQueue.nim(105) addStroke
StrokeQueue.nim(91) add
assign.nim(132) genericSeqAssign
assign.nim(96) genericAssign
assign.nim(69) genericAssignAux
assign.nim(85) genericAssignAux
assign.nim(35) genericAssignAux
assign.nim(24) genericAssignAux
assign.nim(21) genericAssignAux
assign.nim(54) genericAssignAux
gc.nim(465) newObjNoInit
gc.nim(439) rawNewObj
gc.nim(951) collectCT
gc.nim(907) collectCTBody
gc.nim(863) collectZCT
gc.nim(369) forAllChildren
gc.nim(736) nimGCvisit
gc.nim(705) doOperation
gc.nim(221) decRef
system.nim(1104) canBeCycleRoot
SIGSEGV: Illegal storage access. (Attempt to read from nil?)Just realized this, but the LogParser in the first line is actually a file name in which the iterator was inlined. The crash disappears when adding echo repr... statements or slowing the program down enough in another way, or when changing the object in the queue to a ref type. The assignment that seems to cause it is this line. https://github.com/nim-lang/Nim/blob/master/lib/pure/collections/queues.nim#L66
I didn't try that hard yet but couldn't get a simplified example with the same behaviour. Does anyone know what is up with that?
Edit: also doesn't happen in release builds.