@matkuki reported running into an issue with the Fidgetty demo app when running on Windows. It's a bit strange and also apparently only errors when run from the Windows console:
Funny observation: this only happens if I run the demo from the Windows console, if I run it with double-clicking the executable in the explorer, it never throws this error!
Here's the stack trace:
J:\Nim\fidgetty\examples\demo.nim(162) demo
J:\Nim\fidgetty\src\fidgetty\fidget_dev\openglbackend.nim(199) startFidget
C:\Users\matic\.choosenim\toolchains\nim-1.6.8\lib\pure\asyncdispatch.nim(1961) waitFor
C:\Users\matic\.choosenim\toolchains\nim-1.6.8\lib\pure\asyncdispatch.nim(1653) poll
C:\Users\matic\.choosenim\toolchains\nim-1.6.8\lib\pure\asyncdispatch.nim(419) runOnce
C:\Users\matic\.choosenim\toolchains\nim-1.6.8\lib\pure\asyncdispatch.nim(234) processPendingCallbacks
C:\Users\matic\.choosenim\toolchains\nim-1.6.8\lib\pure\asyncmacro.nim(28) runningNimAsyncContinue
J:\Nim\fidgetty\src\fidgetty\fidget_dev\openglbackend.nim(193) runningIter
J:\Nim\fidgetty\src\fidgetty\fidget_dev\opengl\base.nim(172) updateLoop
J:\Nim\fidgetty\src\fidgetty\fidget_dev\opengl\base.nim(139) drawAndSwap
J:\Nim\fidgetty\src\fidgetty\fidget_dev\openglbackend.nim(91) :anonymous
J:\Nim\fidgetty\src\fidgetty\widgets.nim(111) testDemo
C:\Users\matic\.choosenim\toolchains\nim-1.6.8\lib\system\arc.nim(172) nimDestroyAndDispose
C:\Users\matic\.choosenim\toolchains\nim-1.6.8\lib\system\arc.nim(198) nimDecRefIsLast
SIGSEGV: Illegal storage access. (Attempt to read from nil?)
Note that I'm not using any special destructors or finalizers. Just standard ref objects. Also, putting asserts in for the ref objects in this block say everything is allocated correctly.
I don't have a Windows copy, so it's hard for me to debug. Has anyone seen this sorta behavior elsewhere? Also, if it's a compiler bug I'm not sure how to make a reproducible test case.
Thanks @araq, I'll work with @matkuki and see if we can narrow it down. Though the demo app isn't too large, a few hundred lines.
The reason I thought it could be a compiler bug would be that it looks like the some bugs from the early arc days, and that the stack trace becomes nebulous..
Though that could just be due to being in a template of templates section. I'm using a finally block to let the user provide post-widget actions/handling without needing to create a closure/proc. So it could be something in my code there or the compiler getting confused.
@carterza, good thought. I'll take a look, but that section of code should be pure Nim code. There's C libs called but later during rendering.