critbits.nim rawGet causes FieldDefect: field 'key' is not accessible for type 'NodeObj' using 'isLeaf = 255' when run multiple times with -mm:orc
#20400
Labels
Comments
PhilippMDoerner
added a commit
to PhilippMDoerner/Nim
that referenced
this issue
Sep 20, 2022
Reduces the complexity of a statement in `rawGet`. It appears that that statement causes issues when run with `-mm:orc`, as `hasKey` invokes this proc and this can lead to the error `Exception message: field 'key' is not accessible for type 'NodeObj' using 'isLeaf = 255'. Applying this change has shown that the error no longer occurs.
Closed
|
We may be hitting the same bug. While trying to integrate immutable data structures into pararules we're seeing this:
I don't have anything close to a minimal repro unfortunately. You have to clone this fork and in the
It fails without useMalloc too but the error is more obscured. If you change |
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
I have a larger web application I am writing with the prologue framework, which makes use of
hasKeyfromcritbits.nimwhich 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
/sessionaudioand/timestamproutes 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:
asynchttpserverThus 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: 8fc19b9
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 modifying
rawGeta 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.
The text was updated successfully, but these errors were encountered: