status: Column output format with timestamps displayed #9
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This allows administrators to configure between deployments and easily see which deployment they are booted into as well as indicating which is chronologically most recent. This makes the process more user-friendly, rather than requiring the user to remember which deployment checksum corresponds to the most recent upgrade.
This includes several changes to format the code to follow GNU Coding Standards as per the restof rpm-ostree. This includes fixing indentations, adding spaces between identifers and parentheses, replacing "goto print" with an else structure, and reformatting print statements into complete sentences for internationalization.
After a discussion on what the status command should offer a sysadmin, we decided to try a column output format similar to that of systemctl or docker images. This will print the timestamp, a truncated checksum, the osname, and the refspec of each deployment. It also includes a --pretty option to print the information formatted in rows with the full checksum and a title to specify the default and the rollback target.
|
Merged. |
Closed
cgwalters
referenced
this pull request
in cgwalters/rpm-ostree
Feb 2, 2021
I think this changed in a recent refactoring; basically since
we're passing this stack-allocated value to the child spawn
function we need to keep it alive. This of course would
have been caught by Rust...
```
==672376==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc290d9440 at pc 0x55c88c318946 bp 0x7ffc290d8b10 sp 0x7ffc290d8b08
#0 0x55c88c318945 in script_child_setup src/libpriv/rpmostree-scripts.cxx:272
#1 0x7f92089da902 (/lib64/libglib-2.0.so.0+0x9f902)
#2 0x7f92089de20f (/lib64/libglib-2.0.so.0+0xa320f)
#3 0x7f92089de52e (/lib64/libglib-2.0.so.0+0xa352e)
#4 0x7f92089def02 in g_spawn_async_with_pipes (/lib64/libglib-2.0.so.0+0xa3f02)
#5 0x7f9208b7445f (/lib64/libgio-2.0.so.0+0xab45f)
#6 0x7f9208b736d8 in g_subprocess_launcher_spawnv (/lib64/libgio-2.0.so.0+0xaa6d8)
#7 0x55c88c3831b9 in rpmostree_bwrap_execute src/libpriv/rpmostree-bwrap.cxx:504
#8 0x55c88c3836df in rpmostree_bwrap_run_captured src/libpriv/rpmostree-bwrap.cxx:450
#9 0x55c88c31b5f1 in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:469
#10 0x55c88c31ca9d in impl_run_rpm_script src/libpriv/rpmostree-scripts.cxx:588
#11 0x55c88c31d22b in run_script src/libpriv/rpmostree-scripts.cxx:637
#12 0x55c88c31d22b in rpmostree_script_run_sync src/libpriv/rpmostree-scripts.cxx:778
#13 0x55c88c2ef830 in run_script_sync src/libpriv/rpmostree-core.cxx:3661
#14 0x55c88c30afa6 in rpmostree_context_assemble src/libpriv/rpmostree-core.cxx:4422
#15 0x55c88c34a9af in install_packages src/app/rpmostree-compose-builtin-tree.cxx:451
#16 0x55c88c34c174 in impl_install_tree src/app/rpmostree-compose-builtin-tree.cxx:925
#17 0x55c88c350f84 in rpmostree_compose_builtin_tree src/app/rpmostree-compose-builtin-tree.cxx:1421
#18 0x55c88c276ec8 in rpmostree_handle_subcommand src/app/libmain.cxx:405
#19 0x55c88c27827c in rpmostree_main_inner src/app/libmain.cxx:521
#20 0x55c88c27827c in rpmostreecxx::rpmostree_main(rust::cxxbridge1::Slice<rust::cxxbridge1::Str const>) src/app/libmain.cxx:546
#21 0x55c88c271c25 in operator() /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1257
#22 0x55c88c271c25 in trycatch<rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda()>, rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda(char const*)> > /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:997
#23 0x55c88c271c25 in rpmostreecxx$cxxbridge1$rpmostree_main /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1255
#24 0x55c88c0468f7 in rpmostree_rust::ffi::rpmostree_main::hfedda48c684245ce rust/src/lib.rs:25
#25 0x55c88c0468f7 in rpm_ostree::inner_main::hf078b99ca4b270aa rust/src/main.rs:9
#26 0x55c88c0468f7 in rpm_ostree::main::hc0ca527cfaa3f556 rust/src/main.rs:28
#27 0x55c88c046b22 in core::ops::function::FnOnce::call_once::h8567110dac55274e /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
#28 0x55c88c046b22 in std::sys_common::backtrace::__rust_begin_short_backtrace::h1c67f2f52d05cfa0 /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137
#29 0x55c88c045fd7 in main (/usr/bin/rpm-ostree+0xc9fd7)
#30 0x7f92076091e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
#31 0x55c88c045b9d in _start (/usr/bin/rpm-ostree+0xc9b9d)
Address 0x7ffc290d9440 is located in stack of thread T0 at offset 272 in frame
#0 0x55c88c31a1af in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:349
```
cgwalters
referenced
this pull request
in cgwalters/rpm-ostree
Feb 3, 2021
I think this changed in a recent refactoring; basically since
we're passing this stack-allocated value to the child spawn
function we need to keep it alive. This of course would
have been caught by Rust...
```
==672376==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc290d9440 at pc 0x55c88c318946 bp 0x7ffc290d8b10 sp 0x7ffc290d8b08
#0 0x55c88c318945 in script_child_setup src/libpriv/rpmostree-scripts.cxx:272
#1 0x7f92089da902 (/lib64/libglib-2.0.so.0+0x9f902)
#2 0x7f92089de20f (/lib64/libglib-2.0.so.0+0xa320f)
#3 0x7f92089de52e (/lib64/libglib-2.0.so.0+0xa352e)
#4 0x7f92089def02 in g_spawn_async_with_pipes (/lib64/libglib-2.0.so.0+0xa3f02)
#5 0x7f9208b7445f (/lib64/libgio-2.0.so.0+0xab45f)
#6 0x7f9208b736d8 in g_subprocess_launcher_spawnv (/lib64/libgio-2.0.so.0+0xaa6d8)
#7 0x55c88c3831b9 in rpmostree_bwrap_execute src/libpriv/rpmostree-bwrap.cxx:504
#8 0x55c88c3836df in rpmostree_bwrap_run_captured src/libpriv/rpmostree-bwrap.cxx:450
#9 0x55c88c31b5f1 in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:469
#10 0x55c88c31ca9d in impl_run_rpm_script src/libpriv/rpmostree-scripts.cxx:588
#11 0x55c88c31d22b in run_script src/libpriv/rpmostree-scripts.cxx:637
#12 0x55c88c31d22b in rpmostree_script_run_sync src/libpriv/rpmostree-scripts.cxx:778
#13 0x55c88c2ef830 in run_script_sync src/libpriv/rpmostree-core.cxx:3661
#14 0x55c88c30afa6 in rpmostree_context_assemble src/libpriv/rpmostree-core.cxx:4422
#15 0x55c88c34a9af in install_packages src/app/rpmostree-compose-builtin-tree.cxx:451
#16 0x55c88c34c174 in impl_install_tree src/app/rpmostree-compose-builtin-tree.cxx:925
#17 0x55c88c350f84 in rpmostree_compose_builtin_tree src/app/rpmostree-compose-builtin-tree.cxx:1421
#18 0x55c88c276ec8 in rpmostree_handle_subcommand src/app/libmain.cxx:405
#19 0x55c88c27827c in rpmostree_main_inner src/app/libmain.cxx:521
#20 0x55c88c27827c in rpmostreecxx::rpmostree_main(rust::cxxbridge1::Slice<rust::cxxbridge1::Str const>) src/app/libmain.cxx:546
#21 0x55c88c271c25 in operator() /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1257
#22 0x55c88c271c25 in trycatch<rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda()>, rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda(char const*)> > /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:997
#23 0x55c88c271c25 in rpmostreecxx$cxxbridge1$rpmostree_main /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1255
#24 0x55c88c0468f7 in rpmostree_rust::ffi::rpmostree_main::hfedda48c684245ce rust/src/lib.rs:25
#25 0x55c88c0468f7 in rpm_ostree::inner_main::hf078b99ca4b270aa rust/src/main.rs:9
#26 0x55c88c0468f7 in rpm_ostree::main::hc0ca527cfaa3f556 rust/src/main.rs:28
#27 0x55c88c046b22 in core::ops::function::FnOnce::call_once::h8567110dac55274e /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
#28 0x55c88c046b22 in std::sys_common::backtrace::__rust_begin_short_backtrace::h1c67f2f52d05cfa0 /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137
#29 0x55c88c045fd7 in main (/usr/bin/rpm-ostree+0xc9fd7)
#30 0x7f92076091e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
#31 0x55c88c045b9d in _start (/usr/bin/rpm-ostree+0xc9b9d)
Address 0x7ffc290d9440 is located in stack of thread T0 at offset 272 in frame
#0 0x55c88c31a1af in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:349
```
openshift-merge-robot
pushed a commit
that referenced
this pull request
Feb 3, 2021
I think this changed in a recent refactoring; basically since
we're passing this stack-allocated value to the child spawn
function we need to keep it alive. This of course would
have been caught by Rust...
```
==672376==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc290d9440 at pc 0x55c88c318946 bp 0x7ffc290d8b10 sp 0x7ffc290d8b08
#0 0x55c88c318945 in script_child_setup src/libpriv/rpmostree-scripts.cxx:272
#1 0x7f92089da902 (/lib64/libglib-2.0.so.0+0x9f902)
#2 0x7f92089de20f (/lib64/libglib-2.0.so.0+0xa320f)
#3 0x7f92089de52e (/lib64/libglib-2.0.so.0+0xa352e)
#4 0x7f92089def02 in g_spawn_async_with_pipes (/lib64/libglib-2.0.so.0+0xa3f02)
#5 0x7f9208b7445f (/lib64/libgio-2.0.so.0+0xab45f)
#6 0x7f9208b736d8 in g_subprocess_launcher_spawnv (/lib64/libgio-2.0.so.0+0xaa6d8)
#7 0x55c88c3831b9 in rpmostree_bwrap_execute src/libpriv/rpmostree-bwrap.cxx:504
#8 0x55c88c3836df in rpmostree_bwrap_run_captured src/libpriv/rpmostree-bwrap.cxx:450
#9 0x55c88c31b5f1 in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:469
#10 0x55c88c31ca9d in impl_run_rpm_script src/libpriv/rpmostree-scripts.cxx:588
#11 0x55c88c31d22b in run_script src/libpriv/rpmostree-scripts.cxx:637
#12 0x55c88c31d22b in rpmostree_script_run_sync src/libpriv/rpmostree-scripts.cxx:778
#13 0x55c88c2ef830 in run_script_sync src/libpriv/rpmostree-core.cxx:3661
#14 0x55c88c30afa6 in rpmostree_context_assemble src/libpriv/rpmostree-core.cxx:4422
#15 0x55c88c34a9af in install_packages src/app/rpmostree-compose-builtin-tree.cxx:451
#16 0x55c88c34c174 in impl_install_tree src/app/rpmostree-compose-builtin-tree.cxx:925
#17 0x55c88c350f84 in rpmostree_compose_builtin_tree src/app/rpmostree-compose-builtin-tree.cxx:1421
#18 0x55c88c276ec8 in rpmostree_handle_subcommand src/app/libmain.cxx:405
#19 0x55c88c27827c in rpmostree_main_inner src/app/libmain.cxx:521
#20 0x55c88c27827c in rpmostreecxx::rpmostree_main(rust::cxxbridge1::Slice<rust::cxxbridge1::Str const>) src/app/libmain.cxx:546
#21 0x55c88c271c25 in operator() /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1257
#22 0x55c88c271c25 in trycatch<rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda()>, rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda(char const*)> > /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:997
#23 0x55c88c271c25 in rpmostreecxx$cxxbridge1$rpmostree_main /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1255
#24 0x55c88c0468f7 in rpmostree_rust::ffi::rpmostree_main::hfedda48c684245ce rust/src/lib.rs:25
#25 0x55c88c0468f7 in rpm_ostree::inner_main::hf078b99ca4b270aa rust/src/main.rs:9
#26 0x55c88c0468f7 in rpm_ostree::main::hc0ca527cfaa3f556 rust/src/main.rs:28
#27 0x55c88c046b22 in core::ops::function::FnOnce::call_once::h8567110dac55274e /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
#28 0x55c88c046b22 in std::sys_common::backtrace::__rust_begin_short_backtrace::h1c67f2f52d05cfa0 /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137
#29 0x55c88c045fd7 in main (/usr/bin/rpm-ostree+0xc9fd7)
#30 0x7f92076091e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
#31 0x55c88c045b9d in _start (/usr/bin/rpm-ostree+0xc9b9d)
Address 0x7ffc290d9440 is located in stack of thread T0 at offset 272 in frame
#0 0x55c88c31a1af in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:349
```
cgwalters
referenced
this pull request
in cgwalters/rpm-ostree
Feb 6, 2021
This works fine when composing, but for some reason the client side apparently infinite loops inside libsolv: ``` (lldb) thread backtrace * thread #4, name = 'pool-/usr/bin/r' * frame #0: 0x00007fd61b97200f libc.so.6`__memcpy_sse2_unaligned_erms + 623 frame #1: 0x00007fd61cbc88e6 libasan.so.6`__asan::asan_realloc(void*, unsigned long, __sanitizer::BufferedStackTrace*) + 214 frame #2: 0x00007fd61cc4b725 libasan.so.6`__interceptor_realloc + 245 frame #3: 0x00007fd61baec43e libsolv.so.1`solv_realloc + 30 frame #4: 0x00007fd61baf0414 libsolv.so.1`repodata_add_dirstr + 276 frame #5: 0x00007fd61bb6f755 libsolvext.so.1`end_element + 53 frame #6: 0x00007fd61b05855d libxml2.so.2`xmlParseEndTag1.constprop.0 + 317 frame #7: 0x00007fd61b063548 libxml2.so.2`xmlParseTryOrFinish.isra.0 + 888 frame #8: 0x00007fd61af7ed20 libxml2.so.2`xmlParseChunk + 560 frame #9: 0x00007fd61bb727e7 libsolvext.so.1`solv_xmlparser_parse + 183 frame #10: 0x00007fd61bb5ea0e libsolvext.so.1`repo_add_rpmmd + 254 frame #11: 0x000055a4fce7a5f5 rpm-ostree`::load_filelists_cb(repo=<unavailable>, fp=<unavailable>) at dnf-sack.cpp:444:23 frame #12: 0x000055a4fce7cad6 rpm-ostree`load_ext(_DnfSack*, libdnf::Repo*, _hy_repo_repodata, char const*, char const*, int (*)(s_Repo*, _IO_FILE*), _GError**) at dnf-sack.cpp:430:13 frame #13: 0x000055a4fce7df60 rpm-ostree`dnf_sack_load_repo at dnf-sack.cpp:1789:26 frame #14: 0x000055a4fce7eee9 rpm-ostree`dnf_sack_add_repo at dnf-sack.cpp:2217:28 frame #15: 0x000055a4fce7f0fb rpm-ostree`dnf_sack_add_repos at dnf-sack.cpp:2271:32 frame #16: 0x000055a4fce870ee rpm-ostree`dnf_context_setup_sack_with_flags at dnf-context.cpp:1796:29 frame #17: 0x000055a4fcdf757f rpm-ostree`rpmostree_context_download_metadata at rpmostree-core.cxx:1206:44 frame #18: 0x000055a4fcdf95c3 rpm-ostree`rpmostree_context_prepare at rpmostree-core.cxx:2001:48 frame #19: 0x000055a4fce54ab7 rpm-ostree`rpmostree_sysroot_upgrader_prep_layering at rpmostree-sysroot-upgrader.cxx:1018:38 frame #20: 0x000055a4fcdcb143 rpm-ostree`deploy_transaction_execute(_RpmostreedTransaction*, _GCancellable*, _GError**) at rpmostreed-transaction-types.cxx:1445:49 frame #21: 0x000055a4fcdba4cd rpm-ostree`transaction_execute_thread(_GTask*, void*, void*, _GCancellable*) at rpmostreed-transaction.cxx:340:34 frame #22: 0x00007fd61c58f7e2 libgio-2.0.so.0`g_task_thread_pool_thread + 114 frame #23: 0x00007fd61c3d7e54 libglib-2.0.so.0`g_thread_pool_thread_proxy.lto_priv.0 + 116 frame #24: 0x00007fd61c3d52b2 libglib-2.0.so.0`g_thread_proxy + 82 frame #25: 0x00007fd61b8af3f9 libpthread.so.0`start_thread + 233 frame #26: 0x00007fd61b9c9903 libc.so.6`__clone + 67 (lldb) ```
cgwalters
referenced
this pull request
in cgwalters/rpm-ostree
Feb 6, 2021
This works fine when composing, but for some reason the client side apparently infinite loops inside libsolv: ``` (lldb) thread backtrace * thread #4, name = 'pool-/usr/bin/r' * frame #0: 0x00007fd61b97200f libc.so.6`__memcpy_sse2_unaligned_erms + 623 frame #1: 0x00007fd61cbc88e6 libasan.so.6`__asan::asan_realloc(void*, unsigned long, __sanitizer::BufferedStackTrace*) + 214 frame #2: 0x00007fd61cc4b725 libasan.so.6`__interceptor_realloc + 245 frame #3: 0x00007fd61baec43e libsolv.so.1`solv_realloc + 30 frame #4: 0x00007fd61baf0414 libsolv.so.1`repodata_add_dirstr + 276 frame #5: 0x00007fd61bb6f755 libsolvext.so.1`end_element + 53 frame #6: 0x00007fd61b05855d libxml2.so.2`xmlParseEndTag1.constprop.0 + 317 frame #7: 0x00007fd61b063548 libxml2.so.2`xmlParseTryOrFinish.isra.0 + 888 frame #8: 0x00007fd61af7ed20 libxml2.so.2`xmlParseChunk + 560 frame #9: 0x00007fd61bb727e7 libsolvext.so.1`solv_xmlparser_parse + 183 frame #10: 0x00007fd61bb5ea0e libsolvext.so.1`repo_add_rpmmd + 254 frame #11: 0x000055a4fce7a5f5 rpm-ostree`::load_filelists_cb(repo=<unavailable>, fp=<unavailable>) at dnf-sack.cpp:444:23 frame #12: 0x000055a4fce7cad6 rpm-ostree`load_ext(_DnfSack*, libdnf::Repo*, _hy_repo_repodata, char const*, char const*, int (*)(s_Repo*, _IO_FILE*), _GError**) at dnf-sack.cpp:430:13 frame #13: 0x000055a4fce7df60 rpm-ostree`dnf_sack_load_repo at dnf-sack.cpp:1789:26 frame #14: 0x000055a4fce7eee9 rpm-ostree`dnf_sack_add_repo at dnf-sack.cpp:2217:28 frame #15: 0x000055a4fce7f0fb rpm-ostree`dnf_sack_add_repos at dnf-sack.cpp:2271:32 frame #16: 0x000055a4fce870ee rpm-ostree`dnf_context_setup_sack_with_flags at dnf-context.cpp:1796:29 frame #17: 0x000055a4fcdf757f rpm-ostree`rpmostree_context_download_metadata at rpmostree-core.cxx:1206:44 frame #18: 0x000055a4fcdf95c3 rpm-ostree`rpmostree_context_prepare at rpmostree-core.cxx:2001:48 frame #19: 0x000055a4fce54ab7 rpm-ostree`rpmostree_sysroot_upgrader_prep_layering at rpmostree-sysroot-upgrader.cxx:1018:38 frame #20: 0x000055a4fcdcb143 rpm-ostree`deploy_transaction_execute(_RpmostreedTransaction*, _GCancellable*, _GError**) at rpmostreed-transaction-types.cxx:1445:49 frame #21: 0x000055a4fcdba4cd rpm-ostree`transaction_execute_thread(_GTask*, void*, void*, _GCancellable*) at rpmostreed-transaction.cxx:340:34 frame #22: 0x00007fd61c58f7e2 libgio-2.0.so.0`g_task_thread_pool_thread + 114 frame #23: 0x00007fd61c3d7e54 libglib-2.0.so.0`g_thread_pool_thread_proxy.lto_priv.0 + 116 frame #24: 0x00007fd61c3d52b2 libglib-2.0.so.0`g_thread_proxy + 82 frame #25: 0x00007fd61b8af3f9 libpthread.so.0`start_thread + 233 frame #26: 0x00007fd61b9c9903 libc.so.6`__clone + 67 (lldb) ```
cgwalters
referenced
this pull request
in cgwalters/rpm-ostree
Feb 8, 2021
This way we at least get unit test coverage (which... our unit test coverage doesn't do much because our main code paths require privileges or virt). One main blocker to this is that rustc doesn't expose first-class support for this yet: rust-lang/rust#39699 At a practical level this works when building in release mode but fails with `cargo test` for some reason; linker arguments being pruned? Not sure. So I was able to use this when composing to find a bug, but then for some other reason the client side apparently infinite loops inside libsolv. So we're not enabling this yet for those reasons, but let's land the build infrastructure now. ``` (lldb) thread backtrace * thread #4, name = 'pool-/usr/bin/r' * frame #0: 0x00007fd61b97200f libc.so.6`__memcpy_sse2_unaligned_erms + 623 frame #1: 0x00007fd61cbc88e6 libasan.so.6`__asan::asan_realloc(void*, unsigned long, __sanitizer::BufferedStackTrace*) + 214 frame #2: 0x00007fd61cc4b725 libasan.so.6`__interceptor_realloc + 245 frame #3: 0x00007fd61baec43e libsolv.so.1`solv_realloc + 30 frame #4: 0x00007fd61baf0414 libsolv.so.1`repodata_add_dirstr + 276 frame #5: 0x00007fd61bb6f755 libsolvext.so.1`end_element + 53 frame #6: 0x00007fd61b05855d libxml2.so.2`xmlParseEndTag1.constprop.0 + 317 frame #7: 0x00007fd61b063548 libxml2.so.2`xmlParseTryOrFinish.isra.0 + 888 frame #8: 0x00007fd61af7ed20 libxml2.so.2`xmlParseChunk + 560 frame #9: 0x00007fd61bb727e7 libsolvext.so.1`solv_xmlparser_parse + 183 frame #10: 0x00007fd61bb5ea0e libsolvext.so.1`repo_add_rpmmd + 254 frame #11: 0x000055a4fce7a5f5 rpm-ostree`::load_filelists_cb(repo=<unavailable>, fp=<unavailable>) at dnf-sack.cpp:444:23 frame #12: 0x000055a4fce7cad6 rpm-ostree`load_ext(_DnfSack*, libdnf::Repo*, _hy_repo_repodata, char const*, char const*, int (*)(s_Repo*, _IO_FILE*), _GError**) at dnf-sack.cpp:430:13 frame #13: 0x000055a4fce7df60 rpm-ostree`dnf_sack_load_repo at dnf-sack.cpp:1789:26 frame #14: 0x000055a4fce7eee9 rpm-ostree`dnf_sack_add_repo at dnf-sack.cpp:2217:28 frame #15: 0x000055a4fce7f0fb rpm-ostree`dnf_sack_add_repos at dnf-sack.cpp:2271:32 frame #16: 0x000055a4fce870ee rpm-ostree`dnf_context_setup_sack_with_flags at dnf-context.cpp:1796:29 frame #17: 0x000055a4fcdf757f rpm-ostree`rpmostree_context_download_metadata at rpmostree-core.cxx:1206:44 frame #18: 0x000055a4fcdf95c3 rpm-ostree`rpmostree_context_prepare at rpmostree-core.cxx:2001:48 frame #19: 0x000055a4fce54ab7 rpm-ostree`rpmostree_sysroot_upgrader_prep_layering at rpmostree-sysroot-upgrader.cxx:1018:38 frame #20: 0x000055a4fcdcb143 rpm-ostree`deploy_transaction_execute(_RpmostreedTransaction*, _GCancellable*, _GError**) at rpmostreed-transaction-types.cxx:1445:49 frame #21: 0x000055a4fcdba4cd rpm-ostree`transaction_execute_thread(_GTask*, void*, void*, _GCancellable*) at rpmostreed-transaction.cxx:340:34 frame #22: 0x00007fd61c58f7e2 libgio-2.0.so.0`g_task_thread_pool_thread + 114 frame #23: 0x00007fd61c3d7e54 libglib-2.0.so.0`g_thread_pool_thread_proxy.lto_priv.0 + 116 frame #24: 0x00007fd61c3d52b2 libglib-2.0.so.0`g_thread_proxy + 82 frame #25: 0x00007fd61b8af3f9 libpthread.so.0`start_thread + 233 frame #26: 0x00007fd61b9c9903 libc.so.6`__clone + 67 (lldb) ```
cgwalters
referenced
this pull request
in cgwalters/rpm-ostree
Feb 10, 2021
This way we at least get unit test coverage (which... our unit test coverage doesn't do much because our main code paths require privileges or virt). One main blocker to this is that rustc doesn't expose first-class support for this yet: rust-lang/rust#39699 At a practical level this works when building in release mode but fails with `cargo test` for some reason; linker arguments being pruned? Not sure. So I was able to use this when composing to find a bug, but then for some other reason the client side apparently infinite loops inside libsolv. So we're not enabling this yet for those reasons, but let's land the build infrastructure now. ``` (lldb) thread backtrace * thread #4, name = 'pool-/usr/bin/r' * frame #0: 0x00007fd61b97200f libc.so.6`__memcpy_sse2_unaligned_erms + 623 frame #1: 0x00007fd61cbc88e6 libasan.so.6`__asan::asan_realloc(void*, unsigned long, __sanitizer::BufferedStackTrace*) + 214 frame #2: 0x00007fd61cc4b725 libasan.so.6`__interceptor_realloc + 245 frame #3: 0x00007fd61baec43e libsolv.so.1`solv_realloc + 30 frame #4: 0x00007fd61baf0414 libsolv.so.1`repodata_add_dirstr + 276 frame #5: 0x00007fd61bb6f755 libsolvext.so.1`end_element + 53 frame #6: 0x00007fd61b05855d libxml2.so.2`xmlParseEndTag1.constprop.0 + 317 frame #7: 0x00007fd61b063548 libxml2.so.2`xmlParseTryOrFinish.isra.0 + 888 frame #8: 0x00007fd61af7ed20 libxml2.so.2`xmlParseChunk + 560 frame #9: 0x00007fd61bb727e7 libsolvext.so.1`solv_xmlparser_parse + 183 frame #10: 0x00007fd61bb5ea0e libsolvext.so.1`repo_add_rpmmd + 254 frame #11: 0x000055a4fce7a5f5 rpm-ostree`::load_filelists_cb(repo=<unavailable>, fp=<unavailable>) at dnf-sack.cpp:444:23 frame #12: 0x000055a4fce7cad6 rpm-ostree`load_ext(_DnfSack*, libdnf::Repo*, _hy_repo_repodata, char const*, char const*, int (*)(s_Repo*, _IO_FILE*), _GError**) at dnf-sack.cpp:430:13 frame #13: 0x000055a4fce7df60 rpm-ostree`dnf_sack_load_repo at dnf-sack.cpp:1789:26 frame #14: 0x000055a4fce7eee9 rpm-ostree`dnf_sack_add_repo at dnf-sack.cpp:2217:28 frame #15: 0x000055a4fce7f0fb rpm-ostree`dnf_sack_add_repos at dnf-sack.cpp:2271:32 frame #16: 0x000055a4fce870ee rpm-ostree`dnf_context_setup_sack_with_flags at dnf-context.cpp:1796:29 frame #17: 0x000055a4fcdf757f rpm-ostree`rpmostree_context_download_metadata at rpmostree-core.cxx:1206:44 frame #18: 0x000055a4fcdf95c3 rpm-ostree`rpmostree_context_prepare at rpmostree-core.cxx:2001:48 frame #19: 0x000055a4fce54ab7 rpm-ostree`rpmostree_sysroot_upgrader_prep_layering at rpmostree-sysroot-upgrader.cxx:1018:38 frame #20: 0x000055a4fcdcb143 rpm-ostree`deploy_transaction_execute(_RpmostreedTransaction*, _GCancellable*, _GError**) at rpmostreed-transaction-types.cxx:1445:49 frame #21: 0x000055a4fcdba4cd rpm-ostree`transaction_execute_thread(_GTask*, void*, void*, _GCancellable*) at rpmostreed-transaction.cxx:340:34 frame #22: 0x00007fd61c58f7e2 libgio-2.0.so.0`g_task_thread_pool_thread + 114 frame #23: 0x00007fd61c3d7e54 libglib-2.0.so.0`g_thread_pool_thread_proxy.lto_priv.0 + 116 frame #24: 0x00007fd61c3d52b2 libglib-2.0.so.0`g_thread_proxy + 82 frame #25: 0x00007fd61b8af3f9 libpthread.so.0`start_thread + 233 frame #26: 0x00007fd61b9c9903 libc.so.6`__clone + 67 (lldb) ```
openshift-merge-robot
pushed a commit
that referenced
this pull request
Feb 10, 2021
This way we at least get unit test coverage (which... our unit test coverage doesn't do much because our main code paths require privileges or virt). One main blocker to this is that rustc doesn't expose first-class support for this yet: rust-lang/rust#39699 At a practical level this works when building in release mode but fails with `cargo test` for some reason; linker arguments being pruned? Not sure. So I was able to use this when composing to find a bug, but then for some other reason the client side apparently infinite loops inside libsolv. So we're not enabling this yet for those reasons, but let's land the build infrastructure now. ``` (lldb) thread backtrace * thread #4, name = 'pool-/usr/bin/r' * frame #0: 0x00007fd61b97200f libc.so.6`__memcpy_sse2_unaligned_erms + 623 frame #1: 0x00007fd61cbc88e6 libasan.so.6`__asan::asan_realloc(void*, unsigned long, __sanitizer::BufferedStackTrace*) + 214 frame #2: 0x00007fd61cc4b725 libasan.so.6`__interceptor_realloc + 245 frame #3: 0x00007fd61baec43e libsolv.so.1`solv_realloc + 30 frame #4: 0x00007fd61baf0414 libsolv.so.1`repodata_add_dirstr + 276 frame #5: 0x00007fd61bb6f755 libsolvext.so.1`end_element + 53 frame #6: 0x00007fd61b05855d libxml2.so.2`xmlParseEndTag1.constprop.0 + 317 frame #7: 0x00007fd61b063548 libxml2.so.2`xmlParseTryOrFinish.isra.0 + 888 frame #8: 0x00007fd61af7ed20 libxml2.so.2`xmlParseChunk + 560 frame #9: 0x00007fd61bb727e7 libsolvext.so.1`solv_xmlparser_parse + 183 frame #10: 0x00007fd61bb5ea0e libsolvext.so.1`repo_add_rpmmd + 254 frame #11: 0x000055a4fce7a5f5 rpm-ostree`::load_filelists_cb(repo=<unavailable>, fp=<unavailable>) at dnf-sack.cpp:444:23 frame #12: 0x000055a4fce7cad6 rpm-ostree`load_ext(_DnfSack*, libdnf::Repo*, _hy_repo_repodata, char const*, char const*, int (*)(s_Repo*, _IO_FILE*), _GError**) at dnf-sack.cpp:430:13 frame #13: 0x000055a4fce7df60 rpm-ostree`dnf_sack_load_repo at dnf-sack.cpp:1789:26 frame #14: 0x000055a4fce7eee9 rpm-ostree`dnf_sack_add_repo at dnf-sack.cpp:2217:28 frame #15: 0x000055a4fce7f0fb rpm-ostree`dnf_sack_add_repos at dnf-sack.cpp:2271:32 frame #16: 0x000055a4fce870ee rpm-ostree`dnf_context_setup_sack_with_flags at dnf-context.cpp:1796:29 frame #17: 0x000055a4fcdf757f rpm-ostree`rpmostree_context_download_metadata at rpmostree-core.cxx:1206:44 frame #18: 0x000055a4fcdf95c3 rpm-ostree`rpmostree_context_prepare at rpmostree-core.cxx:2001:48 frame #19: 0x000055a4fce54ab7 rpm-ostree`rpmostree_sysroot_upgrader_prep_layering at rpmostree-sysroot-upgrader.cxx:1018:38 frame #20: 0x000055a4fcdcb143 rpm-ostree`deploy_transaction_execute(_RpmostreedTransaction*, _GCancellable*, _GError**) at rpmostreed-transaction-types.cxx:1445:49 frame #21: 0x000055a4fcdba4cd rpm-ostree`transaction_execute_thread(_GTask*, void*, void*, _GCancellable*) at rpmostreed-transaction.cxx:340:34 frame #22: 0x00007fd61c58f7e2 libgio-2.0.so.0`g_task_thread_pool_thread + 114 frame #23: 0x00007fd61c3d7e54 libglib-2.0.so.0`g_thread_pool_thread_proxy.lto_priv.0 + 116 frame #24: 0x00007fd61c3d52b2 libglib-2.0.so.0`g_thread_proxy + 82 frame #25: 0x00007fd61b8af3f9 libpthread.so.0`start_thread + 233 frame #26: 0x00007fd61b9c9903 libc.so.6`__clone + 67 (lldb) ```
stefanberger
added a commit
to stefanberger/rpm-ostree
that referenced
this pull request
Apr 5, 2021
Remove the unnecessary builder causing memory leaks like this one:
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f60bd2fe3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
coreos#1 0x7f60bca6cbb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
coreos#2 0x7f60bcaa54f2 in g_variant_type_copy (/lib64/libglib-2.0.so.0+0x944f2)
coreos#3 0x7f60bcaa3384 in g_variant_builder_init (/lib64/libglib-2.0.so.0+0x92384)
coreos#4 0x55e5bb3120d3 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
coreos#5 0x7f60bc89cb38 (/lib64/libostree-1.so.1+0x49b38)
coreos#6 0x7f60bc8a5e1a (/lib64/libostree-1.so.1+0x52e1a)
coreos#7 0x7f60bc8a622b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
coreos#8 0x55e5bb307e6e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1551
coreos#9 0x7f60bca92401 (/lib64/libglib-2.0.so.0+0x81401)
coreos#10 0x7f60bc12d3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
coreos#11 0x7f60bc05ab52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
stefanberger
added a commit
to stefanberger/rpm-ostree
that referenced
this pull request
Apr 5, 2021
Direct leak of 13 byte(s) in 1 object(s) allocated from:
#0 0x7fb8d6c8f3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
coreos#1 0x7fb8d6330bb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
coreos#2 0x7fb8d6345fe3 in g_strdup (/lib64/libglib-2.0.so.0+0x70fe3)
coreos#3 0x7fb8d63726ef (/lib64/libglib-2.0.so.0+0x9d6ef)
coreos#4 0x7fb8d63728ff in g_variant_get_va (/lib64/libglib-2.0.so.0+0x9d8ff)
coreos#5 0x7fb8d6372aa8 in g_variant_dict_lookup (/lib64/libglib-2.0.so.0+0x9daa8)
coreos#6 0x5628e40c25b4 in filter_xattrs_impl src/libpriv/rpmostree-postprocess.cxx:1469
coreos#7 0x5628e40c25b4 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
coreos#8 0x7fb8d622db38 (/lib64/libostree-1.so.1+0x49b38)
coreos#9 0x7fb8d6235b98 (/lib64/libostree-1.so.1+0x51b98)
coreos#10 0x7fb8d6236fd5 (/lib64/libostree-1.so.1+0x52fd5)
coreos#11 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#12 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#13 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#14 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#15 0x7fb8d623722b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
coreos#16 0x5628e40b7e5e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1547
coreos#17 0x7fb8d6356401 (/lib64/libglib-2.0.so.0+0x81401)
coreos#18 0x7fb8d5abe3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
coreos#19 0x7fb8d59ebb52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
stefanberger
added a commit
to stefanberger/rpm-ostree
that referenced
this pull request
Apr 5, 2021
Direct leak of 13 byte(s) in 1 object(s) allocated from:
#0 0x7fb8d6c8f3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
coreos#1 0x7fb8d6330bb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
coreos#2 0x7fb8d6345fe3 in g_strdup (/lib64/libglib-2.0.so.0+0x70fe3)
coreos#3 0x7fb8d63726ef (/lib64/libglib-2.0.so.0+0x9d6ef)
coreos#4 0x7fb8d63728ff in g_variant_get_va (/lib64/libglib-2.0.so.0+0x9d8ff)
coreos#5 0x7fb8d6372aa8 in g_variant_dict_lookup (/lib64/libglib-2.0.so.0+0x9daa8)
coreos#6 0x5628e40c25b4 in filter_xattrs_impl src/libpriv/rpmostree-postprocess.cxx:1469
coreos#7 0x5628e40c25b4 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
coreos#8 0x7fb8d622db38 (/lib64/libostree-1.so.1+0x49b38)
coreos#9 0x7fb8d6235b98 (/lib64/libostree-1.so.1+0x51b98)
coreos#10 0x7fb8d6236fd5 (/lib64/libostree-1.so.1+0x52fd5)
coreos#11 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#12 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#13 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#14 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#15 0x7fb8d623722b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
coreos#16 0x5628e40b7e5e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1547
coreos#17 0x7fb8d6356401 (/lib64/libglib-2.0.so.0+0x81401)
coreos#18 0x7fb8d5abe3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
coreos#19 0x7fb8d59ebb52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
stefanberger
added a commit
to stefanberger/rpm-ostree
that referenced
this pull request
Apr 5, 2021
Direct leak of 13 byte(s) in 1 object(s) allocated from:
#0 0x7fb8d6c8f3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
coreos#1 0x7fb8d6330bb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
coreos#2 0x7fb8d6345fe3 in g_strdup (/lib64/libglib-2.0.so.0+0x70fe3)
coreos#3 0x7fb8d63726ef (/lib64/libglib-2.0.so.0+0x9d6ef)
coreos#4 0x7fb8d63728ff in g_variant_get_va (/lib64/libglib-2.0.so.0+0x9d8ff)
coreos#5 0x7fb8d6372aa8 in g_variant_dict_lookup (/lib64/libglib-2.0.so.0+0x9daa8)
coreos#6 0x5628e40c25b4 in filter_xattrs_impl src/libpriv/rpmostree-postprocess.cxx:1469
coreos#7 0x5628e40c25b4 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
coreos#8 0x7fb8d622db38 (/lib64/libostree-1.so.1+0x49b38)
coreos#9 0x7fb8d6235b98 (/lib64/libostree-1.so.1+0x51b98)
coreos#10 0x7fb8d6236fd5 (/lib64/libostree-1.so.1+0x52fd5)
coreos#11 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#12 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#13 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#14 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#15 0x7fb8d623722b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
coreos#16 0x5628e40b7e5e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1547
coreos#17 0x7fb8d6356401 (/lib64/libglib-2.0.so.0+0x81401)
coreos#18 0x7fb8d5abe3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
coreos#19 0x7fb8d59ebb52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
stefanberger
added a commit
to stefanberger/rpm-ostree
that referenced
this pull request
Apr 5, 2021
Direct leak of 13 byte(s) in 1 object(s) allocated from:
#0 0x7fb8d6c8f3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
coreos#1 0x7fb8d6330bb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
coreos#2 0x7fb8d6345fe3 in g_strdup (/lib64/libglib-2.0.so.0+0x70fe3)
coreos#3 0x7fb8d63726ef (/lib64/libglib-2.0.so.0+0x9d6ef)
coreos#4 0x7fb8d63728ff in g_variant_get_va (/lib64/libglib-2.0.so.0+0x9d8ff)
coreos#5 0x7fb8d6372aa8 in g_variant_dict_lookup (/lib64/libglib-2.0.so.0+0x9daa8)
coreos#6 0x5628e40c25b4 in filter_xattrs_impl src/libpriv/rpmostree-postprocess.cxx:1469
coreos#7 0x5628e40c25b4 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
coreos#8 0x7fb8d622db38 (/lib64/libostree-1.so.1+0x49b38)
coreos#9 0x7fb8d6235b98 (/lib64/libostree-1.so.1+0x51b98)
coreos#10 0x7fb8d6236fd5 (/lib64/libostree-1.so.1+0x52fd5)
coreos#11 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#12 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#13 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#14 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#15 0x7fb8d623722b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
coreos#16 0x5628e40b7e5e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1547
coreos#17 0x7fb8d6356401 (/lib64/libglib-2.0.so.0+0x81401)
coreos#18 0x7fb8d5abe3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
coreos#19 0x7fb8d59ebb52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
stefanberger
added a commit
to stefanberger/rpm-ostree
that referenced
this pull request
Apr 5, 2021
Direct leak of 13 byte(s) in 1 object(s) allocated from:
#0 0x7fb8d6c8f3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
coreos#1 0x7fb8d6330bb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
coreos#2 0x7fb8d6345fe3 in g_strdup (/lib64/libglib-2.0.so.0+0x70fe3)
coreos#3 0x7fb8d63726ef (/lib64/libglib-2.0.so.0+0x9d6ef)
coreos#4 0x7fb8d63728ff in g_variant_get_va (/lib64/libglib-2.0.so.0+0x9d8ff)
coreos#5 0x7fb8d6372aa8 in g_variant_dict_lookup (/lib64/libglib-2.0.so.0+0x9daa8)
coreos#6 0x5628e40c25b4 in filter_xattrs_impl src/libpriv/rpmostree-postprocess.cxx:1469
coreos#7 0x5628e40c25b4 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
coreos#8 0x7fb8d622db38 (/lib64/libostree-1.so.1+0x49b38)
coreos#9 0x7fb8d6235b98 (/lib64/libostree-1.so.1+0x51b98)
coreos#10 0x7fb8d6236fd5 (/lib64/libostree-1.so.1+0x52fd5)
coreos#11 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#12 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#13 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#14 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#15 0x7fb8d623722b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
coreos#16 0x5628e40b7e5e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1547
coreos#17 0x7fb8d6356401 (/lib64/libglib-2.0.so.0+0x81401)
coreos#18 0x7fb8d5abe3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
coreos#19 0x7fb8d59ebb52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
stefanberger
added a commit
to stefanberger/rpm-ostree
that referenced
this pull request
Apr 6, 2021
Remove the unnecessary builder causing memory leaks like this one:
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f60bd2fe3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
coreos#1 0x7f60bca6cbb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
coreos#2 0x7f60bcaa54f2 in g_variant_type_copy (/lib64/libglib-2.0.so.0+0x944f2)
coreos#3 0x7f60bcaa3384 in g_variant_builder_init (/lib64/libglib-2.0.so.0+0x92384)
coreos#4 0x55e5bb3120d3 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
coreos#5 0x7f60bc89cb38 (/lib64/libostree-1.so.1+0x49b38)
coreos#6 0x7f60bc8a5e1a (/lib64/libostree-1.so.1+0x52e1a)
coreos#7 0x7f60bc8a622b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
coreos#8 0x55e5bb307e6e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1551
coreos#9 0x7f60bca92401 (/lib64/libglib-2.0.so.0+0x81401)
coreos#10 0x7f60bc12d3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
coreos#11 0x7f60bc05ab52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
stefanberger
added a commit
to stefanberger/rpm-ostree
that referenced
this pull request
Apr 6, 2021
Direct leak of 13 byte(s) in 1 object(s) allocated from:
#0 0x7fb8d6c8f3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
coreos#1 0x7fb8d6330bb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
coreos#2 0x7fb8d6345fe3 in g_strdup (/lib64/libglib-2.0.so.0+0x70fe3)
coreos#3 0x7fb8d63726ef (/lib64/libglib-2.0.so.0+0x9d6ef)
coreos#4 0x7fb8d63728ff in g_variant_get_va (/lib64/libglib-2.0.so.0+0x9d8ff)
coreos#5 0x7fb8d6372aa8 in g_variant_dict_lookup (/lib64/libglib-2.0.so.0+0x9daa8)
coreos#6 0x5628e40c25b4 in filter_xattrs_impl src/libpriv/rpmostree-postprocess.cxx:1469
coreos#7 0x5628e40c25b4 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
coreos#8 0x7fb8d622db38 (/lib64/libostree-1.so.1+0x49b38)
coreos#9 0x7fb8d6235b98 (/lib64/libostree-1.so.1+0x51b98)
coreos#10 0x7fb8d6236fd5 (/lib64/libostree-1.so.1+0x52fd5)
coreos#11 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#12 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#13 0x7fb8d6236a0f (/lib64/libostree-1.so.1+0x52a0f)
coreos#14 0x7fb8d623706b (/lib64/libostree-1.so.1+0x5306b)
coreos#15 0x7fb8d623722b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
coreos#16 0x5628e40b7e5e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1547
coreos#17 0x7fb8d6356401 (/lib64/libglib-2.0.so.0+0x81401)
coreos#18 0x7fb8d5abe3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
coreos#19 0x7fb8d59ebb52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
stefanberger
added a commit
to stefanberger/rpm-ostree
that referenced
this pull request
Apr 9, 2021
Remove the unnecessary builder causing memory leaks like this one:
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f60bd2fe3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
coreos#1 0x7f60bca6cbb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
coreos#2 0x7f60bcaa54f2 in g_variant_type_copy (/lib64/libglib-2.0.so.0+0x944f2)
coreos#3 0x7f60bcaa3384 in g_variant_builder_init (/lib64/libglib-2.0.so.0+0x92384)
coreos#4 0x55e5bb3120d3 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
coreos#5 0x7f60bc89cb38 (/lib64/libostree-1.so.1+0x49b38)
coreos#6 0x7f60bc8a5e1a (/lib64/libostree-1.so.1+0x52e1a)
coreos#7 0x7f60bc8a622b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
coreos#8 0x55e5bb307e6e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1551
coreos#9 0x7f60bca92401 (/lib64/libglib-2.0.so.0+0x81401)
coreos#10 0x7f60bc12d3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
coreos#11 0x7f60bc05ab52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
stefanberger
added a commit
to stefanberger/rpm-ostree
that referenced
this pull request
Apr 12, 2021
Remove the unnecessary builder causing memory leaks like this one:
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f60bd2fe3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
coreos#1 0x7f60bca6cbb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
coreos#2 0x7f60bcaa54f2 in g_variant_type_copy (/lib64/libglib-2.0.so.0+0x944f2)
coreos#3 0x7f60bcaa3384 in g_variant_builder_init (/lib64/libglib-2.0.so.0+0x92384)
coreos#4 0x55e5bb3120d3 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
coreos#5 0x7f60bc89cb38 (/lib64/libostree-1.so.1+0x49b38)
coreos#6 0x7f60bc8a5e1a (/lib64/libostree-1.so.1+0x52e1a)
coreos#7 0x7f60bc8a622b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
coreos#8 0x55e5bb307e6e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1551
coreos#9 0x7f60bca92401 (/lib64/libglib-2.0.so.0+0x81401)
coreos#10 0x7f60bc12d3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
coreos#11 0x7f60bc05ab52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This iteration of the status command prints the output in a column display. It now prints the timestamp of the deployment in the form YYYY-MM-DD HH:MM:SS, as well as a truncated checksum, and the osname and refspec. The command also now has a --pretty option which prints the output in a row format for readability and user friendliness. This command will be important for a system administrator who needs to see details of the deployments and know which version of the OS they are booted into.