-
Notifications
You must be signed in to change notification settings - Fork 293
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
lyd_print doesn't work #5
Comments
Could you provide how you use lyd_print()? It prints just the data tree you pass via the |
// earlier // later.. |
try this:
|
Still dumps the modules:
This is where a request is made ..
|
libyang stores only schemas inside the context, data parsed by |
do not call |
Ok, got it. Its working now. I misunderstood due to the following comment: Context is used to hold all information about schemas. Usually, the application is supposed to work with a single context in which libyang is holding all data models and other internal information according to which the data will be processed and validated. Therefore, both schema and data trees are connected with a specific context. |
ok, actually the data tree is connected with the context - strings are stored inside a dictionary that is part of the context and it points to the schema which is also inside the context. However, data tree is not as tightly connected with context as schemas which are internally stored as part of the context. I will try to clarify it more in documentation, thanks. |
$ touch empty.xml $ sysrepocfg --import=empty.xml --format=xml --datastore=running ThreadSanitizer:DEADLYSIGNAL ==12949==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f8b121637f8 bp 0x000000000001 sp 0x7fff4257f350 T12949) ==12949==The signal is caused by a READ memory access. ==12949==Hint: address points to the zero page. #0 lyxml_parse_mem /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/libyang/src/xml.c:1257:14 (libyang.so.1+0x377f8) CESNET#1 lyd_parse_ /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/libyang/src/tree_data.c:951:15 (libyang.so.1+0xb7e79) CESNET#2 lyd_parse_data_ /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/libyang/src/tree_data.c:1039:12 (libyang.so.1+0xa6476) CESNET#3 lyd_parse_fd_ /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/libyang/src/tree_data.c:1074:11 (libyang.so.1+0xa66be) CESNET#4 lyd_parse_path /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/libyang/src/tree_data.c:1117:11 (libyang.so.1+0xa67e1) CESNET#5 step_load_data /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/sysrepo/src/executables/sysrepocfg.c:235:17 (sysrepocfg+0x4d3041) CESNET#6 op_import /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/sysrepo/src/executables/sysrepocfg.c:299:9 (sysrepocfg+0x4d206a) CESNET#7 main /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/sysrepo/src/executables/sysrepocfg.c:871:14 (sysrepocfg+0x4d1832) CESNET#8 __libc_start_main <null> (libc.so.6+0x23dbc) CESNET#9 _start /build/glibc-2.32/csu/../sysdeps/x86_64/start.S:120 (sysrepocfg+0x4235d9)
$ touch empty.xml $ sysrepocfg --import=empty.xml --format=xml --datastore=running ThreadSanitizer:DEADLYSIGNAL ==12949==ERROR: ThreadSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f8b121637f8 bp 0x000000000001 sp 0x7fff4257f350 T12949) ==12949==The signal is caused by a READ memory access. ==12949==Hint: address points to the zero page. #0 lyxml_parse_mem /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/libyang/src/xml.c:1257:14 (libyang.so.1+0x377f8) CESNET#1 lyd_parse_ /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/libyang/src/tree_data.c:951:15 (libyang.so.1+0xb7e79) CESNET#2 lyd_parse_data_ /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/libyang/src/tree_data.c:1039:12 (libyang.so.1+0xa6476) CESNET#3 lyd_parse_fd_ /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/libyang/src/tree_data.c:1074:11 (libyang.so.1+0xa66be) CESNET#4 lyd_parse_path /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/libyang/src/tree_data.c:1117:11 (libyang.so.1+0xa67e1) CESNET#5 step_load_data /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/sysrepo/src/executables/sysrepocfg.c:235:17 (sysrepocfg+0x4d3041) CESNET#6 op_import /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/sysrepo/src/executables/sysrepocfg.c:299:9 (sysrepocfg+0x4d206a) CESNET#7 main /home/jkt/work/cesnet/gerrit/CzechLight/cla-sysrepo/submodules/dependencies/sysrepo/src/executables/sysrepocfg.c:871:14 (sysrepocfg+0x4d1832) CESNET#8 __libc_start_main <null> (libc.so.6+0x23dbc) CESNET#9 _start /build/glibc-2.32/csu/../sysdeps/x86_64/start.S:120 (sysrepocfg+0x4235d9) Fixes: sysrepo/sysrepo#2294
libnetconf2's test `test_server_thread` eventually ends up in this stack trace: libyang/src/tree_schema.c:3288:16: runtime error: null pointer passed as argument 1, which is declared to never be null /nix/store/ypih4394q488ljr421x8jak55vmr0ckn-glibc-2.32-dev/include/string.h:44:28: note: nonnull attribute specified here #0 0x7f565ebf8f6e in lys_node_dup_recursion libyang/src/tree_schema.c:3288:9 CESNET#1 0x7f565ebf3409 in lys_node_dup libyang/src/tree_schema.c:3609:14 CESNET#2 0x7f565ebbf62c in yang_check_deviation libyang/src/parser_yang.c:4646:26 CESNET#3 0x7f565eba6531 in yang_check_sub_module libyang/src/parser_yang.c:4784:13 CESNET#4 0x7f565eba3d1c in yang_read_module libyang/src/parser_yang.c:2705:13 CESNET#5 0x7f565ebd1077 in lys_parse_mem_ libyang/src/tree_schema.c:1083:15 CESNET#6 0x7f565ebd31ab in lys_parse_fd_ libyang/src/tree_schema.c:1271:14 CESNET#7 0x7f565e92f291 in ly_ctx_load_localfile libyang/src/context.c:916:39 CESNET#8 0x7f565e92c31b in ly_ctx_load_sub_module libyang/src/context.c:1063:19 CESNET#9 0x7f565e92fdcc in ly_ctx_load_module libyang/src/context.c:1102:12 CESNET#10 0x597422 in main libnetconf2/tests/test_server_thread.c:686:5 CESNET#11 0x7f565dc98dbc in __libc_start_main (/nix/store/kah5n342wz4i0s9lz9ka4bgz91xa2i94-glibc-2.32/lib/libc.so.6+0x23dbc) CESNET#12 0x42a4d9 in _start /build/glibc-2.32/csu/../sysdeps/x86_64/start.S:120 In other words, it would call `memcpy` with the source parameter being NULL, which is [explicitly said to be undefined behavior](https://www.imperialviolet.org/2016/06/26/nonnull.html).
clang 16 with ASAN and UBSAN flag this as UB because it's performing pointer arithmetic on a NULL pointer, which is not allowed in C. The test suite of libyang-cpp triggers this behavior: 2/4 Test CESNET#1: test_context .....................***Failed 0.77 sec libyang[0]: Unexpected end-of-input. (path: Line number 1.) libyang[0]: Data model "invalid" not found in local searchdirs. libyang[0]: Loading "invalid" module failed. libyang[0]: Feature "nonexisting" not found in module "mod1". libyang[0]: Data model "doesnt-exist" not found in local searchdirs. libyang[0]: Loading "doesnt-exist" module failed. /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/xpath.c:239:24: runtime error: applying zero offset to null pointer #0 0x7f4054b4d168 in print_expr_str /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/xpath.c:239:24 CESNET#1 0x7f4054b2ba16 in print_expr_struct_debug /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/xpath.c:276:9 CESNET#2 0x7f4054b27209 in lyxp_expr_parse /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/xpath.c:3216:5 CESNET#3 0x7f40543582ab in ly_path_parse /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/path.c:339:5 CESNET#4 0x7f405441c8d4 in lyd_find_path /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/tree_data.c:3028:11 CESNET#5 0x7f4055751848 in libyang::DataNode::findPath(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> const&, libyang::OutputNodes) const /home/ci/src/cesnet-gerrit-public/CzechLight/libyang-cpp/src/DataNode.cpp:220:16 CESNET#6 0x5424d5 in DOCTEST_ANON_FUNC_2() /home/ci/src/cesnet-gerrit-public/CzechLight/libyang-cpp/tests/context.cpp:346:9 CESNET#7 0x5ffbf7 in doctest::Context::run() /home/ci/target/include/doctest/doctest.h:7007:21 CESNET#8 0x60556d in main /home/ci/target/include/doctest/doctest.h:7085:71 CESNET#9 0x7f4055048b49 in __libc_start_call_main /usr/src/debug/glibc-2.37-1.fc38.x86_64/csu/../sysdeps/nptl/libc_start_call_main.h:58:16 CESNET#10 0x7f4055048c0a in __libc_start_main@GLIBC_2.2.5 /usr/src/debug/glibc-2.37-1.fc38.x86_64/csu/../csu/libc-start.c:360:3 CESNET#11 0x4450f4 in _start (/home/ci/build/CzechLight/libyang-cpp/test_context+0x4450f4) (BuildId: b2cbc6b91e2c885110ddbf157ff7a19e41ed0306) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/xpath.c:239:24 in I'm getting this on Fedora 38 and on Arch, but for some reason I cannot seem to hit the original issue on NixOS. Strange, but it's an UB anyway. Fixes: 1696178 xpath UPDATE do not use memstream
clang 16 with ASAN and UBSAN flag this as UB because it's performing pointer arithmetic on a NULL pointer, which is not allowed in C. The test suite of libyang-cpp triggers this behavior: 2/4 Test #1: test_context .....................***Failed 0.77 sec libyang[0]: Unexpected end-of-input. (path: Line number 1.) libyang[0]: Data model "invalid" not found in local searchdirs. libyang[0]: Loading "invalid" module failed. libyang[0]: Feature "nonexisting" not found in module "mod1". libyang[0]: Data model "doesnt-exist" not found in local searchdirs. libyang[0]: Loading "doesnt-exist" module failed. /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/xpath.c:239:24: runtime error: applying zero offset to null pointer #0 0x7f4054b4d168 in print_expr_str /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/xpath.c:239:24 #1 0x7f4054b2ba16 in print_expr_struct_debug /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/xpath.c:276:9 #2 0x7f4054b27209 in lyxp_expr_parse /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/xpath.c:3216:5 #3 0x7f40543582ab in ly_path_parse /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/path.c:339:5 #4 0x7f405441c8d4 in lyd_find_path /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/tree_data.c:3028:11 #5 0x7f4055751848 in libyang::DataNode::findPath(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> const&, libyang::OutputNodes) const /home/ci/src/cesnet-gerrit-public/CzechLight/libyang-cpp/src/DataNode.cpp:220:16 #6 0x5424d5 in DOCTEST_ANON_FUNC_2() /home/ci/src/cesnet-gerrit-public/CzechLight/libyang-cpp/tests/context.cpp:346:9 #7 0x5ffbf7 in doctest::Context::run() /home/ci/target/include/doctest/doctest.h:7007:21 #8 0x60556d in main /home/ci/target/include/doctest/doctest.h:7085:71 #9 0x7f4055048b49 in __libc_start_call_main /usr/src/debug/glibc-2.37-1.fc38.x86_64/csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #10 0x7f4055048c0a in __libc_start_main@GLIBC_2.2.5 /usr/src/debug/glibc-2.37-1.fc38.x86_64/csu/../csu/libc-start.c:360:3 #11 0x4450f4 in _start (/home/ci/build/CzechLight/libyang-cpp/test_context+0x4450f4) (BuildId: b2cbc6b91e2c885110ddbf157ff7a19e41ed0306) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/xpath.c:239:24 in I'm getting this on Fedora 38 and on Arch, but for some reason I cannot seem to hit the original issue on NixOS. Strange, but it's an UB anyway. Fixes: 1696178 xpath UPDATE do not use memstream
The recent patch was sending a NULL pointer to ly_strncmp which passed the NULL to strncmp. However, strncmp arguments are attributed as nonnull which make undefined behaviour sanitizer unhappy. /build/libyang/src/ly_common.c:114:30: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:160:33: note: nonnull attribute specified here #0 0x79c7f4278907 in ly_strncmp /build/libyang/src/ly_common.c:114:14 CESNET#1 0x79c7f43faf24 in lyd_new_path_ /build/libyang/src/tree_data_new.c:1736:55 CESNET#2 0x79c7f43fdf61 in lyd_new_path2 /build/libyang/src/tree_data_new.c:1861:12 CESNET#3 0x79c7f5249b24 in sr_lyd_new_path /build/dependencies/sysrepo/src/ly_wrap.c:644:9 CESNET#4 0x79c7f52ec883 in sr_edit_add /build/dependencies/sysrepo/src/edit_diff.c:3765:20 CESNET#5 0x79c7f5195824 in sr_delete_item /build/dependencies/sysrepo/src/sysrepo.c:3453:16 CESNET#6 0x5c9e51a98f6e in clear_test /build/sysrepo/tests/test_edit.c:120:5 CESNET#7 0x79c7f56da98c (/usr/lib/libcmocka.so.0+0x698c) (BuildId: 4d284c2a057f6dbeaa60a5e68cb5891237d21ae1) CESNET#8 0x79c7f56db51c in _cmocka_run_group_tests (/usr/lib/libcmocka.so.0+0x751c) (BuildId: 4d284c2a057f6dbeaa60a5e68cb5891237d21ae1) CESNET#9 0x5c9e51a91f41 in main /build/sysrepo/tests/test_edit.c:1571:12 CESNET#10 0x79c7f3b4ec87 (/usr/lib/libc.so.6+0x25c87) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) CESNET#11 0x79c7f3b4ed4b in __libc_start_main (/usr/lib/libc.so.6+0x25d4b) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) CESNET#12 0x5c9e5195a2b4 in _start (/build/sysrepo/build-clang-asan/tests/test_edit+0x3a2b4) (BuildId: dc378717130c22094495ee54dcfbdc3254b5f981) Fixes: ed74a24 tree data UPDATE recognize special JSON [null] value
The recent patch was sending a NULL pointer to ly_strncmp which passed the NULL to strncmp. However, strncmp arguments are attributed as nonnull which make undefined behaviour sanitizer unhappy. This ubsan report appeared when running sysrepo tests: /build/libyang/src/ly_common.c:114:30: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:160:33: note: nonnull attribute specified here #0 0x79c7f4278907 in ly_strncmp /build/libyang/src/ly_common.c:114:14 CESNET#1 0x79c7f43faf24 in lyd_new_path_ /build/libyang/src/tree_data_new.c:1736:55 CESNET#2 0x79c7f43fdf61 in lyd_new_path2 /build/libyang/src/tree_data_new.c:1861:12 CESNET#3 0x79c7f5249b24 in sr_lyd_new_path /build/dependencies/sysrepo/src/ly_wrap.c:644:9 CESNET#4 0x79c7f52ec883 in sr_edit_add /build/dependencies/sysrepo/src/edit_diff.c:3765:20 CESNET#5 0x79c7f5195824 in sr_delete_item /build/dependencies/sysrepo/src/sysrepo.c:3453:16 CESNET#6 0x5c9e51a98f6e in clear_test /build/sysrepo/tests/test_edit.c:120:5 CESNET#7 0x79c7f56da98c (/usr/lib/libcmocka.so.0+0x698c) (BuildId: 4d284c2a057f6dbeaa60a5e68cb5891237d21ae1) CESNET#8 0x79c7f56db51c in _cmocka_run_group_tests (/usr/lib/libcmocka.so.0+0x751c) (BuildId: 4d284c2a057f6dbeaa60a5e68cb5891237d21ae1) CESNET#9 0x5c9e51a91f41 in main /build/sysrepo/tests/test_edit.c:1571:12 CESNET#10 0x79c7f3b4ec87 (/usr/lib/libc.so.6+0x25c87) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) CESNET#11 0x79c7f3b4ed4b in __libc_start_main (/usr/lib/libc.so.6+0x25d4b) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) CESNET#12 0x5c9e5195a2b4 in _start (/build/sysrepo/build-clang-asan/tests/test_edit+0x3a2b4) (BuildId: dc378717130c22094495ee54dcfbdc3254b5f981) Fixes: ed74a24 tree data UPDATE recognize special JSON [null] value
The recent patch was sending a NULL pointer to ly_strncmp which passed the NULL to strncmp. However, strncmp arguments are attributed as nonnull which make undefined behaviour sanitizer unhappy. This ubsan report appeared when running sysrepo tests: /build/libyang/src/ly_common.c:114:30: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:160:33: note: nonnull attribute specified here #0 0x79c7f4278907 in ly_strncmp /build/libyang/src/ly_common.c:114:14 CESNET#1 0x79c7f43faf24 in lyd_new_path_ /build/libyang/src/tree_data_new.c:1736:55 CESNET#2 0x79c7f43fdf61 in lyd_new_path2 /build/libyang/src/tree_data_new.c:1861:12 CESNET#3 0x79c7f5249b24 in sr_lyd_new_path /build/dependencies/sysrepo/src/ly_wrap.c:644:9 CESNET#4 0x79c7f52ec883 in sr_edit_add /build/dependencies/sysrepo/src/edit_diff.c:3765:20 CESNET#5 0x79c7f5195824 in sr_delete_item /build/dependencies/sysrepo/src/sysrepo.c:3453:16 CESNET#6 0x5c9e51a98f6e in clear_test /build/sysrepo/tests/test_edit.c:120:5 CESNET#7 0x79c7f56da98c (/usr/lib/libcmocka.so.0+0x698c) (BuildId: 4d284c2a057f6dbeaa60a5e68cb5891237d21ae1) CESNET#8 0x79c7f56db51c in _cmocka_run_group_tests (/usr/lib/libcmocka.so.0+0x751c) (BuildId: 4d284c2a057f6dbeaa60a5e68cb5891237d21ae1) CESNET#9 0x5c9e51a91f41 in main /build/sysrepo/tests/test_edit.c:1571:12 CESNET#10 0x79c7f3b4ec87 (/usr/lib/libc.so.6+0x25c87) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) CESNET#11 0x79c7f3b4ed4b in __libc_start_main (/usr/lib/libc.so.6+0x25d4b) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) CESNET#12 0x5c9e5195a2b4 in _start (/build/sysrepo/build-clang-asan/tests/test_edit+0x3a2b4) (BuildId: dc378717130c22094495ee54dcfbdc3254b5f981) Fixes: ed74a24 tree data UPDATE recognize special JSON [null] value
The recent patch was sending a NULL pointer to ly_strncmp which passed the NULL to strncmp. However, strncmp arguments are attributed as nonnull which make undefined behaviour sanitizer unhappy. This ubsan report appeared when running sysrepo tests: /build/libyang/src/ly_common.c:114:30: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:160:33: note: nonnull attribute specified here #0 0x79c7f4278907 in ly_strncmp /build/libyang/src/ly_common.c:114:14 #1 0x79c7f43faf24 in lyd_new_path_ /build/libyang/src/tree_data_new.c:1736:55 #2 0x79c7f43fdf61 in lyd_new_path2 /build/libyang/src/tree_data_new.c:1861:12 #3 0x79c7f5249b24 in sr_lyd_new_path /build/dependencies/sysrepo/src/ly_wrap.c:644:9 #4 0x79c7f52ec883 in sr_edit_add /build/dependencies/sysrepo/src/edit_diff.c:3765:20 #5 0x79c7f5195824 in sr_delete_item /build/dependencies/sysrepo/src/sysrepo.c:3453:16 #6 0x5c9e51a98f6e in clear_test /build/sysrepo/tests/test_edit.c:120:5 #7 0x79c7f56da98c (/usr/lib/libcmocka.so.0+0x698c) (BuildId: 4d284c2a057f6dbeaa60a5e68cb5891237d21ae1) #8 0x79c7f56db51c in _cmocka_run_group_tests (/usr/lib/libcmocka.so.0+0x751c) (BuildId: 4d284c2a057f6dbeaa60a5e68cb5891237d21ae1) #9 0x5c9e51a91f41 in main /build/sysrepo/tests/test_edit.c:1571:12 #10 0x79c7f3b4ec87 (/usr/lib/libc.so.6+0x25c87) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) #11 0x79c7f3b4ed4b in __libc_start_main (/usr/lib/libc.so.6+0x25d4b) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) #12 0x5c9e5195a2b4 in _start (/build/sysrepo/build-clang-asan/tests/test_edit+0x3a2b4) (BuildId: dc378717130c22094495ee54dcfbdc3254b5f981) Fixes: ed74a24 tree data UPDATE recognize special JSON [null] value
Calling lyd_print() dumps the loaded schemas not the data:
How do I dump/parse/access the data which was added via lyd_parse()
The text was updated successfully, but these errors were encountered: