lyd_validate() fails when list have multiple lists at same level.

[vishaldhingra]

Hi,

I have a yang model, with list having multiple lists as below :

+--rw staticd
              +--rw route-list* [prefix]
               +--rw prefix       inet:ip-prefix
                 +--rw path-list* [distance tag table-id]
               |
               +--rw src-list* [src-prefix]
                 +--rw src-prefix    inet:ipv6-prefix
                 +--rw path-list* [distance tag table-id]

If i tries to configure this model with specific set of keys then lyd_validate fails.
I am getting below error

Duplicated instance of "src-list" list.

For the details i have attached the sample code with yang model, to reproduce the issue.
This folder contains 3 sub folders bin, src ,inc

1. Go to bin folder, make clean; make all
2. execute ./libyang_scale binary.

I will give you an error.
However as a work around, If i use container at the top of every list then this problem is not coming.

I am creating a data tree in yang.c, xpaths are defined in macros starting with
#define XPATH_PREFIX_

list_with_in_list.zip

libyang version =  latest master

Any pointers would be helpful.

[rwestphal]

It looks like a bug indeed since your test program works fine when libyang is built with -DENABLE_CACHE=OFF.

[chiragshah6]

@michalvasko Can someone please help look into this? It is a blocker to our key development.

[michalvasko]

Hi,
sorry, but I have other work with high priority and have no time left for issues. But fine, since you asked, I tried this and the whole problem were the canonical values. It turns out it was all quite messed up so I tried to make it somehow better but it is still far from perfect. However, only performance should be affected and your use-case should work now.

Regards,
Michal

[chiragshah6]

@michalvasko Thanks for quick fix/cleanup of canonical values. We have validated the fix and it works or the use case reported in this issue. Though scaling can be an issue but for now we want to avoid additional containers.

Could you please help cherry-pick this change to master so frr can integrate into its workflow.

[michalvasko]

Hi,
I would rather not merge it into master, that is not how we use the branches. It will get there along all the other current devel changes on the next release (which I am not able to tell you when it will be, few weeks to few months).

Regards,
Michal