[YANGTOOLS-876] Submodule with augment from another module throws NullPointerException Created: 12/Apr/18  Updated: 16/Apr/18  Resolved: 16/Apr/18

Status: Resolved
Project: yangtools
Component/s: None
Affects Version/s: 1.2.2, 1.1.2, 2.0.3
Fix Version/s: 1.1.4, 1.2.3, 2.0.4

Type: Bug Priority: Medium
Reporter: Michal Cmarada Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File Nullpointer.txt     Text File modules.txt    

 Description   

ietf-ipv6-router-advertisements submodule which augments ipv6 container from ietf-ip, causes build to fail with NullPointerException:
       Target type not yet generated: container ipv6

see attachment for stack-trace.

To reproduce this error use patch https://gerrit.fd.io/r/#/c/11658/.

The patch contains a lot of models, because it is hard to reproduce the bug, but it is definitely caused by submodule hc2vpp-ietf-ipv6-router-advertisements and its augmentation for ipv6.

If this module is changed to a regular module and used as import instead of include then everything works.

There are two cases, where the bug can be observed:

  • first one shows the build failure (Steps 1 and 2) 
  • second shows the same error but on run-time (steps 3 - 6),
    by deleting three unrelated models (dhcp@2018-01-03.yang, sfc-ioam-sb-pot@2017-01-12.yang, vpp-nsh@2017-03-15.yang) build succeeds but run-time fails.

 

 

 

 Comments   
Comment by Robert Varga [ 12/Apr/18 ]

It would seem this is related to ModuleDependencyInfo.sort() – which would explain why it is hard to replicate. Can you confirm if the error is suppressed when hc2vpp-ietf-ipv6-unicast-routing imports ietf-ip?

Comment by Robert Varga [ 12/Apr/18 ]

Also, can you capture the modules being passed as input and update the patch to re-create the problem?

Comment by Robert Varga [ 12/Apr/18 ]

Furthermore, if there is a FD.io issue depending on this, can you link it in as being blocked by this issue?

Comment by Michal Cmarada [ 13/Apr/18 ]

yes, when I added ietf-ip to parent module both build and runtime errors disappeared. Will do some more tests and if I hit the bug again I will report it here.

Comment by Michal Cmarada [ 13/Apr/18 ]

Not sure if you had this in mind, but i found a warning that the submodule was not found in input files:

1st case - build failure
14:32:25 [WARNING] Submodule SubmoduleEffectiveStatementImpl{name=hc2vpp-ietf-ipv6-router-advertisements, namespace=urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing, revision=2018-03-13, prefix=v6ur, yangVersion=1.1} not found in input files
2nd case - fail on runtime (warning is from build log)
[WARNING] Submodule SubmoduleEffectiveStatementImpl{name=hc2vpp-ietf-ipv6-router-advertisements, namespace=urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing, revision=2018-03-13, prefix=v6ur, yangVersion=1.1} not found in input files
I can see this warning in both cases when it fails on build and even in runtime.

Comment by Michal Cmarada [ 16/Apr/18 ]

added output for modules from List<Module> sort(final Module... modules) method. see modules.txt

Comment by Robert Varga [ 16/Apr/18 ]

The problem is we are inlining statements from the submodule, but not the import statement. This leads to the module being not tracked as depending on ietf-ip and being processed before ietf-ip. Inlining the import statement should fix this issue.

Generated at Wed Feb 07 20:54:33 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.