ORC runs into infinite recursion #22927
Labels
Comments
|
Well, you should figure out which type is wrongly classified by There is a handy function, which can be used for this task: proc isCyclic(t: typedesc): bool {.magic: "TypeTrait".} =
## Returns true if the type can potentially form a cyclic type |
|
Hi @ringabout, thank you so much for your quick reply. MyNode* = ref object
yaml*: YamlNode
dependencies*: OrderedSet[MyNode]
parent*: MyNode
case kind*: NodeKind
of cOne:
discard
of cOther:
anotherReference*: MyNodeDifferent instances of How to proceed? With your input, maybe I can manage to create a minimum failing example. |
Yeah, it seems that 71dc929 exposed a pre-existing issue, which means it was not a regression. Did you use it in the multiple threads? |
No, everything is single-threaded here. I'm still working on a minimum breaking example. |
|
Unfortunately, I did not manage to get the breaking example shorter than the following. Also, you need to have
So it may be that something inside nimyaml is breaking the ORC (@flyx), but even then I think ORC should not crash. import yaml, yaml/dom
type
YItem = object
items {.defaultVal: @[].}: seq[YItem]
entry: YEntry
yaml {.transient.}: YamlNode
YEntryKind = enum
tkBasic
YEntry = object
case kind: YEntryKind
of tkBasic: basicEntry: string
yaml {.transient.}: YamlNode
ZIdentifier = ref object
item: ZItem
parent: ZIdentifier
ZItem = ref object
y: YItem
ids: ZIdentifier
func fillYamlNodes(obj: var YItem, y: YamlNode) =
obj.yaml = y
for i, x in obj.items.mpairs:
fillYamlNodes(x, y["items"][i])
obj.entry.yaml = y["entry"]
proc constructChild(s: var YamlStream, c: ConstructionContext, result: var YEntry) =
var res: string
constructChild(s, c, res)
result = YEntry(kind: tkBasic, basicEntry: res)
proc newItem(y: YItem): ZItem =
result = ZItem(y: y)
result.ids = ZIdentifier(item: result)
proc myFunc() =
var node: YamlNode
load("""
entry: int
items:
- entry: int
""", node)
var stream = represent(node, tsAll, asNone)
discard stream.next()
var y: YItem
construct(stream, y)
y.fillYamlNodes(node)
discard newItem(y)
var i = 0
while i < 100:
echo $i
myFunc()
i.inc()The output is as follows: Does this help you to reproduce the ORC failure? |
|
This happens also with current NimYAML 2.0.0: import yaml, yaml/dom
type
YItem = object
items {.defaultVal: @[].}: seq[YItem]
entry: YEntry
yaml {.transient.}: YamlNode
YEntryKind = enum
tkBasic
YEntry = object
case kind: YEntryKind
of tkBasic: basicEntry: string
yaml {.transient.}: YamlNode
ZIdentifier = ref object
item: ZItem
parent: ZIdentifier
ZItem = ref object
y: YItem
ids: ZIdentifier
func fillYamlNodes(obj: var YItem, y: YamlNode) =
obj.yaml = y
for i, x in obj.items.mpairs:
fillYamlNodes(x, y["items"][i])
obj.entry.yaml = y["entry"]
proc constructObject(
ctx: var ConstructionContext,
result: var YEntry
) =
var res: string
ctx.constructObject(res)
result = YEntry(kind: tkBasic, basicEntry: res)
proc newItem(y: YItem): ZItem =
result = ZItem(y: y)
result.ids = ZIdentifier(item: result)
proc myFunc() =
var node: YamlNode
load("""
entry: int
items:
- entry: int
""", node)
var stream = represent(node)
discard stream.next()
var y: YItem
construct(stream, y)
y.fillYamlNodes(node)
discard newItem(y)
var i = 0
while i < 100:
echo $i
myFunc()
i.inc()Similar output with slightly different stacktrace. What stands out is that the stack trace is wrong:
which is also wrong since There a a few lines in NimYAML specifically for ORC but they only concern some calls to |
|
I'm looking into this issue with One of the valgrind errors |
|
I can reproduce the valgrind errors, also with Nim 2.0.2, but I am still not able to debug the Nim internals. |
|
I get: |
Araq
added a commit
that referenced
this issue
Jun 12, 2024
narimiran
pushed a commit
that referenced
this issue
Jun 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
I can manage ORC to run into an apparently infinite recursion, which obviously should not happen.
Nim Version
The commit that breaks ORC for me is 71dc929.
It works with 02be212 but fails with 71dc929.
Current Output
Expected Output
Possible Solution
Revert or fix 71dc929
Additional Information
If I skip the test
attach_and_update, the testattach_signalsucceeds, so there obviously is a dependency on code that ran previously.But this makes it unclear to me how to create a minimal failing example.
Any input is appreciated.
The text was updated successfully, but these errors were encountered: