-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] parseData gives unexpected notification element #14
Comments
These have to be parsed in a special way, via libyang's |
Can you try this patch? https://gerrit.cesnet.cz/c/CzechLight/libyang-cpp/+/6416 |
Thank you for your fast reply. I downloaded and applied the patch but seems it doesn't build. Added this I could build the repo and use it. I still get
but it might be a bad format of the notification by my part, I'm currently checking it. I need a clarification though, if I want to send the notification with sysrepo on |
Oops, it's actually a series of patches, you'll need:
Nice timing, i pushed these just a minute ago :). Can you please check the doxygen comments in these patches and report back if it's all clear now? You can find some extra information and usage patterns in the test suite, but please let me know if the docs can be made any clearer. |
Also, the error path is probably wrong, there's very likely a memory leak. But I need CESNET/libyang#2077 fixed first to actually test the exception handling. In the meanwhile, I would not run this on untrusted input :). |
Thank you for your time, with the new patches all our tests pass now. |
Quick note. Given the following notifications: {
"ietf-restconf:notification" : {
"test:eventTime" : "2013-12-21T00:01:00Z",
"test:application_new": {
"application": {
"app_type": "my-types:CLIENT"
}
}
}
}
{
"ietf-restconf:notification" : {
"test:application_new": {
"application": {
"app_type": "my-types:CLIENT"
}
},
"test:eventTime" : "2013-12-21T00:01:00Z"
}
} the first gets parsed while the second throws an exception. Is this a bug or a feature? Is there some kind of parameter order enforcement that I'm not aware of? |
Your example has |
There is ODR violation in libyang tests reported by ASan which breaks our CI builds. This commit temporarily (until this gets solved in upstream) pins the libyang version to 3.0.18 which builds just fine. The log from ASan: 52/60 Test #31: utest_plugins .....................***Failed 1.22 sec [==========] tests: Running 4 test(s). [ RUN ] test_add_invalid [ OK ] test_add_invalid [ RUN ] test_add_simple ================================================================= ==2826==ERROR: AddressSanitizer: odr-violation (0x7f6d170dcb40): [1] size=24 'ly_version_so' /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/ly_common.c:43 [2] size=24 'ly_version_so' /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/ly_common.c:43 These globals were registered at these points: [1]: #0 0x437ffa in __asan_register_globals (/home/ci/build/github/CESNET/libyang/tests/utest_plugins+0x437ffa) (BuildId: e79d14f37e59b6533b66d19363b25fea9e324edb) #1 0x7f6d16691b9e in asan.module_ctor ly_common.c #2 0x7f6d1aad7236 in call_init /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-init.c:74:3 #3 0x7f6d1aad7236 in call_init /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-init.c:26:1 #4 0x7f6d1aad732c in _dl_init /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-init.c:121:5 #5 0x7f6d1aad35c1 in _dl_catch_exception /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-catch.c:211:7 #6 0x7f6d1aaddeeb in dl_open_worker /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-open.c:827:5 #7 0x7f6d1aad3522 in _dl_catch_exception /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-catch.c:237:8 #8 0x7f6d1aade2e3 in _dl_open /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-open.c:903:17 #9 0x7f6d1a7b5713 in dlopen_doit /usr/src/debug/glibc-2.37-18.fc38.x86_64/dlfcn/dlopen.c:56:15 #10 0x7f6d1aad3522 in _dl_catch_exception /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-catch.c:237:8 #11 0x7f6d1aad3678 in _dl_catch_error /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-catch.c:256:19 #12 0x7f6d1a7b51f2 in _dlerror_run /usr/src/debug/glibc-2.37-18.fc38.x86_64/dlfcn/dlerror.c:138:17 #13 0x7f6d1a7b57ce /usr/src/debug/glibc-2.37-18.fc38.x86_64/dlfcn/dlopen.c:71:10 #14 0x7f6d1a7b57ce in dlopen@@GLIBC_2.34 /usr/src/debug/glibc-2.37-18.fc38.x86_64/dlfcn/dlopen.c:81:12 #15 0x485f82 in dlopen (/home/ci/build/github/CESNET/libyang/tests/utest_plugins+0x485f82) (BuildId: e79d14f37e59b6533b66d19363b25fea9e324edb) #16 0xcb5ee3 in plugins_load_module /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/plugins.c:378:17 #17 0xcb5e67 in lyplg_add /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/plugins.c:589:11 #18 0xea2a60 in test_add_simple /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/tests/utests/basic/test_plugins.c:50:5 #19 0x7f6d1aac218f (/lib64/libcmocka.so.0+0x618f) (BuildId: 785844a0941c0bde763740a981d056f60aa9c7b7) #20 0x7f6d1aac2904 in _cmocka_run_group_tests (/lib64/libcmocka.so.0+0x6904) (BuildId: 785844a0941c0bde763740a981d056f60aa9c7b7) #21 0xea21a2 in main /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/tests/utests/basic/test_plugins.c:152:12 Change-Id: Id8a4771296d2e85de2ec29fbd17046d280d2eda2
We installed some modules on sysrepo containing the following snippet:
during some tests we tried to create a notification from a json file
This leads to a crash with the following error:
Using newPath()/newPath2() to create the notification node by node works, but receiving the data as json objects would be easier to parse them.
Am I missing something?
The text was updated successfully, but these errors were encountered: