Infinite loop caused by formatpkg.Print

[jpc4242]

Hi Tal:
I'm opening this as a discussion because I'm not sure if it should be an issue in puccini or in kutil.

I created a very simple CSAR file. I can't attach the zip file here. So here is the content:

TOSCA-Metadata/TOSCA.meta

TOSCA-Meta-File-Version: 1.0
CSAR-Version: 1.1
Created-By: JPC
Entry-Definitions: Definitions/main.yaml

Definitions/main.yaml

tosca_definitions_version: tosca_simple_yaml_1_2
description: Find the puccini infinite loop
node_types:
  jpc.dummynode:
    derived_from: tosca.nodes.Root
    properties:
      dummyprop:
        type: string
topology_template:
  substitution_mappings:
    node_type: jpc.dummynode
  node_templates:
    topnode:
      type: jpc.dummynode
      properties:
        dummyprop: dummy

puccini-tosca parse enters an infinite loop. After some debugging, I found that this loop happens here:

// in puccini-tosca/commands/parse.go, inside "var parseCommand"
                if (filter == "") && (len(dumpPhases) == 0) {
                        logJPC.Debug("JPC before Print")
                        formatpkg.Print(s, format, terminal.Stdout, strict, pretty) // NEVER RETURNS!!!
                        logJPC.Debug("JPC after Print")
                }

Adding -r "*" to the command line skips that part of the code and the program finishes normally.

I see that formatpkg is defined in imports as formatpkg "github.com/tliron/kutil/format". Unfortunately my golang knowledge is really small, so I have no idea how could I substitute that by a local copy and play with that. So the problem may be in kutil itself or in puccini creating some kind of structure referencing itself (if you redirect the command output to a file, it grows without bound until you stop the command and the file shows ever-increasing indentation levels)

EDIT: I think that the problem is caused by puccini creating a circula reference that then is followed ad infinitum by formatpkg.
I changed the formatpkg vall by this:

                if (filter == "") && (len(dumpPhases) == 0) {
                        logJPC.Debug("JPC before Print")
                        //formatpkg.Print(s, format, terminal.Stdout, strict, pretty)
                        fmt.Println(s)
                        fmt.Println(s.Substitution)
                        fmt.Println(s.Substitution.ServiceTemplate)
                        logJPC.Debug("JPC after Print")
                }

and the output is:

juan@jpclap:~/toscas/findloop$ puccini-tosca parse   sample.zip
&{Find the puccini infinite loop map[topnode:0xc0000f6510] map[] map[] map[] map[] map[] 0xc000492f50 map[] 0xc0001358c0}
&{0xc0003a2720 jpc.dummynode map[] map[] map[] map[] map[] map[]}
&{Find the puccini infinite loop map[topnode:0xc0000f6510] map[] map[] map[] map[] map[] 0xc000492f50 map[] 0xc0001358c0}

The first and third lines are identical. The servicetemplate points to a substitution that points back to the same servicetemplate --> circular reference.
I don't know what role those pointers play, so I'm not sure what the fix should be. Maybe kutil could detect circular dependencies and use some references in that case? (similar to "$ref" in openapi)

[tliron]

Thanks! This is definitely a bug and deserving of an "issue".

As for debugging other libraries, here's how you do it:

1. Clone locally
2. In Puccini's. go.mod use the "replace" directive to use your local copy instead of the one on github. You'll see it already there and commented it out because I do that a lot...

[jpc4242]

thanks.Should I open the issue or are you already doing it?
BTW.: I just edited the text above with some extra info

[tliron]

There's probably a need to add a traverse tag to avoid the infinite loop. I'll look into it next week.

[tliron]

Thanks to your detective work I was very quickly able to find the bug. It was my latest changes to substitution mapping handling, I forgot some tags. Oops. See this commit.