Open PhilippMDoerner opened 2 years ago
We may be hitting the same bug. While trying to integrate immutable data structures into pararules we're seeing this:
Error: unhandled exception: field 'nodes' is not accessible for type 'MapNode' using 'kind = 1' [FieldDefect]
I don't have anything close to a minimal repro unfortunately. You have to clone this fork and in the parazoa
branch run:
nim r -d:useMalloc tests/test1.nim
It fails without useMalloc too but the error is more obscured. If you change tests/config.nims
to use refc
the tests run successfully.
I need a reproducible test case.
Doesn't @oakes's message contain one? Here is the direct link to the branch of interest: https://github.com/ul/pararules/tree/parazoa
I understand it's not a minimal case but reproducible nevertheless.
What happened?
I have a larger web application I am writing with the prologue framework, which makes use of
hasKey
fromcritbits.nim
which in turn makes use ofrawGet
. Normally everything works perfectly fine, all HTTP endpoints are perfect.However, when making multiple requests in short succession, under some circumstances (namely when triggering the
/sessionaudio
and/timestamp
routes together repeatedly) it causes the error:I have no understanding of what causes this bug, as it does a) not appear consistently and b) does not occur in code that I have any understanding of.
I can say the following:
asynchttpserver
Thus the error appears to be specific to orc and httpx (?).
Nim Version
Nim Compiler Version 1.7.1 [Linux: amd64] Compiled at 2022-08-23 Copyright (c) 2006-2022 by Andreas Rumpf
git hash: 8fc19b9e1291017b89148a3747fa77efdaf040e2 active boot switches: -d:release
Current Standard Output Logs
Expected Standard Output Logs
No response
Possible Solution
I have troubleshot the passages together with ringabout. We narrowed the issue down to the proc
rawGet
. We further found a solution, as apparently all it takes is modifyingrawGet
a little bit to look like this:As I have no understanding on why this actually fixes things, I'll quote ringabout here:
Additional Information
We essentially already have the solution (though I still don't know why that's a bug/problem) thanks to ringabout! I'll write up the PR to apply their change.