src/tree_data_sorted.c:1160: LY_ERR lyds_create_metadata(struct lyd_node *, struct lyd_meta **): Assertion `leader && (!leader->prev->next || (leader->schema != leader->prev->schema))' failed. #2223
Comments
|
I have tried to reproduce the problem but no luck. Your instructions make no sense to me. get the latest devel of everything - so libyang and sysrepo? In that case libyang-cpp cannot be compiled even if I manually apply commit I also tried to reproduce the problem with just sysrepo, but I didn't get the assert error. My initial suspicion is that the problem will not be with the |
Sorry for that. Use the current
Yes. We have a fair number of downstream projects, so it's essentially a "flag day" update for us, and we have a pre-merge CI to make sure that either everything works, or no breaking changes are merged. Changes for libyang-cpp/sysrepo-cpp have not been merged to their respective
For sysrepo-cpp, it's:
The SHAs are different because we've moved a bit since my original report; the old ones should work, but we're on these now.
With the following patch in place: diff --git a/src/tree_data.c b/src/tree_data.c
index 5158f939e..fc962bc39 100644
--- a/src/tree_data.c
+++ b/src/tree_data.c
@@ -761,6 +761,8 @@ lyd_insert_node(struct lyd_node *parent, struct lyd_node **first_sibling_p, stru
lyd_insert_node_ordby_schema(parent, &first_sibling, node);
} else if (lyds_is_supported(node) &&
(lyd_find_sibling_schema(first_sibling, node->schema, &leader) == LY_SUCCESS)) {
+ assert(leader);
+ assert(!leader->prev->next || (leader->schema != leader->prev->schema));
ret = lyds_insert(&first_sibling, &leader, node);
if (ret) {
/* The operation on the sorting tree unexpectedly failed due to some internal issue,I'm now hitting that assert: |
|
Do you need anything else to reproduce and/or fix this? It's one of the blockers for us switching to the new 2.2/3/whatever SW stack. |
|
Sorry I haven't replied yet. I'll try to look into it on Monday. I'll be sure to ask if I get stuck on something. |
|
I have successfully compiled the projects. When running the tests using |
|
These tests are using CMake test fixtures to install the required YANG modules and env variables to run against a non-standard sysrepo repository/SHM locations. Running them via sysrepoctl \
--install yang/iana-hardware@2018-03-13.yang \
--install yang/ietf-hardware@2018-03-13.yang \
--enable-feature hardware-sensor \
--enable-feature hardware-state \
--install yang/ietf-alarms@2019-09-11.yang \
--enable-feature alarm-shelving \
--enable-feature alarm-summary \
--install yang/velia-alarms@2022-07-12.yang \
--install tests/yang/sysrepo-ietf-alarms@2022-02-17.yang(Here is the relevant fixture setup in CMake.) Note -- this will bypass the init/cleanup stuff we have in the test setup, so do not mix this direct invocation with running through |
A hash must be re-inserted on additional sorting, otherwise the parent will have the wrong reference to the first instance of the schema. Refs CESNET#2223
A hash must be re-inserted on additional sorting, otherwise the parent will have the wrong reference to the first instance of the schema. Refs #2223
|
The tests should pass. Update the libyang devel branch. |
|
thanks |
velia's test suite started triggering an internal assert in libyang. This has worked prior that migration to the v2.2 of libyang., so it's a regression somewhere along the way, and I cannot bisect that due to API changes. Here's how to reproduce:
develof everythingThe backtrace looks like:
The edits that are being pushed are, going first:
{ "ietf-hardware:hardware": { "last-change": "2024-04-10T01:51:04-00:00", "component": [ { "name": "ne", "class": "iana-hardware:chassis", "mfg-name": "CESNET", "state": { "oper-state": "enabled" } }, { "name": "ne:power", "class": "iana-hardware:sensor", "parent": "ne", "state": { "oper-state": "enabled" }, "sensor-data": { "value": 0, "value-type": "watts", "value-scale": "micro", "value-precision": 0, "oper-status": "ok" } }, { "name": "ne:psu", "class": "iana-hardware:power-supply", "parent": "ne", "state": { "oper-state": "enabled" } }, { "name": "ne:psu:child", "class": "iana-hardware:sensor", "parent": "ne:psu", "state": { "oper-state": "enabled" }, "sensor-data": { "value": 12000, "value-type": "volts-DC", "value-scale": "milli", "value-precision": 0, "oper-status": "ok" } }, { "name": "ne:temperature-cpu", "class": "iana-hardware:sensor", "parent": "ne", "state": { "oper-state": "enabled" }, "sensor-data": { "value": 41800, "value-type": "celsius", "value-scale": "milli", "value-precision": 0, "oper-status": "ok" } } ] } }and then this one as the second one:
{ "ietf-hardware:hardware": { "last-change": "2024-04-10T01:51:05-00:00", "component": [ { "name": "ne", "class": "iana-hardware:chassis", "mfg-name": "CESNET", "state": { "oper-state": "enabled" } }, { "name": "ne:power", "class": "iana-hardware:sensor", "parent": "ne", "state": { "oper-state": "enabled" }, "sensor-data": { "value": 0, "value-type": "watts", "value-scale": "micro", "value-precision": 0, "oper-status": "ok" } }, { "name": "ne:psu", "class": "iana-hardware:power-supply", "parent": "ne", "state": { "oper-state": "enabled" } }, { "name": "ne:psu:child", "class": "iana-hardware:sensor", "parent": "ne:psu", "state": { "oper-state": "enabled" }, "sensor-data": { "value": 12000, "value-type": "volts-DC", "value-scale": "milli", "value-precision": 0, "oper-status": "ok" } }, { "name": "ne:temperature-cpu", "class": "iana-hardware:sensor", "parent": "ne", "state": { "oper-state": "enabled" }, "sensor-data": { "value": 41800, "value-type": "celsius", "value-scale": "milli", "value-precision": 0, "oper-status": "ok" } } ] } }and the thrid one:
{ "ietf-hardware:hardware": { "last-change": "2024-04-10T01:51:05-00:00", "component": [ { "name": "ne", "class": "iana-hardware:chassis", "mfg-name": "CESNET", "state": { "oper-state": "enabled" } }, { "name": "ne:power", "class": "iana-hardware:sensor", "parent": "ne", "state": { "oper-state": "enabled" }, "sensor-data": { "value": 0, "value-type": "watts", "value-scale": "micro", "value-precision": 0, "oper-status": "ok" } }, { "name": "ne:psu", "class": "iana-hardware:power-supply", "parent": "ne", "state": { "oper-state": "enabled" } }, { "name": "ne:psu:child", "class": "iana-hardware:sensor", "parent": "ne:psu", "state": { "oper-state": "enabled" }, "sensor-data": { "value": 12000, "value-type": "volts-DC", "value-scale": "milli", "value-precision": 0, "oper-status": "ok" } }, { "name": "ne:temperature-cpu", "class": "iana-hardware:sensor", "parent": "ne", "state": { "oper-state": "enabled" }, "sensor-data": { "value": 41800, "value-type": "celsius", "value-scale": "milli", "value-precision": 0, "oper-status": "ok" } } ] } }which is followed by this one which crashes:
{ "ietf-hardware:hardware": { "last-change": "2024-04-10T01:51:05-00:00", "component": [ { "name": "ne", "class": "iana-hardware:chassis", "mfg-name": "CESNET", "state": { "oper-state": "enabled" } }, { "name": "ne:power", "class": "iana-hardware:sensor", "parent": "ne", "state": { "oper-state": "enabled" }, "sensor-data": { "value": 11222333, "value-type": "watts", "value-scale": "micro", "value-precision": 0, "oper-status": "ok" } }, { "name": "ne:psu", "class": "iana-hardware:power-supply", "parent": "ne", "state": { "oper-state": "disabled" } }, { "name": "ne:psu:child" }, { "name": "ne:temperature-cpu", "class": "iana-hardware:sensor", "parent": "ne", "state": { "oper-state": "enabled" }, "sensor-data": { "value": 222, "value-type": "celsius", "value-scale": "milli", "value-precision": 0, "oper-status": "ok" } } ] }, "sysrepo:discard-items": "/ietf-hardware:hardware/component[name='ne:psu:child']" }...maybe these will help you reproduce the bug without compiling our projects.
The text was updated successfully, but these errors were encountered: