This repository was archived by the owner on Aug 6, 2020. It is now read-only.
Revert "Don't call "plymouth quit""#5
Closed
abbradar wants to merge 1 commit intoNixOS:nixos-v230from
Closed
Conversation
This reverts commit cbee77f.
7 tasks
Member
|
Applied, thanks! |
7 tasks
edolstra
pushed a commit
that referenced
this pull request
Jul 28, 2016
This makes systemctl robust regarding journal truncation. This is a follow-up for 2cf4172 Fixes: Core was generated by `./systemctl status systemd-journald'. Program terminated with signal SIGBUS, Bus error. PID 8569 - core TID 8569: #0 0x00007f246cc89ed6 __memcmp_sse4_1 #1 0x0000557ebbc6f42c journal_file_init_header #2 0x0000557ebbc77262 journal_file_open #3 0x0000557ebbc42999 file_type_wanted #4 0x0000557ebbc42e08 add_any_file #5 0x0000557ebbc43832 add_directory #6 0x0000557ebbc4401c add_root_directory #7 0x0000557ebbc442e9 add_root_directory #8 0x0000557ebbc446fc add_search_paths #9 0x0000557ebbbacb5e show_journal_by_unit #10 0x0000557ebbb8376d print_status_info #11 0x0000557ebbb86a0b show_one #12 0x0000557ebbb87954 show #13 0x0000557ebbc20b1f dispatch_verb #14 0x0000557ebbb90615 systemctl_main #15 0x0000557ebbb9159f main #16 0x00007f246cb3e731 __libc_start_main #17 0x0000557ebbb75ae9 _start
vcunat
pushed a commit
to vcunat/systemd
that referenced
this pull request
Nov 5, 2016
Fixes: Oct 20 09:10:49 systemd-sysusers[144]: Direct leak of 20 byte(s) in 1 object(s) allocated from: Oct 20 09:10:49 systemd-sysusers[144]: #0 0x7f3565a13e60 in malloc (/lib64/libasan.so.3+0xc6e60) Oct 20 09:10:49 systemd-sysusers[144]: NixOS#1 0x7f3565526bd0 in malloc_multiply src/basic/alloc-util.h:70 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#2 0x7f356552cb55 in tempfn_xxxxxx src/basic/fileio.c:1116 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#3 0x7f356552c4f0 in fopen_temporary src/basic/fileio.c:1042 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#4 0x7f356555e00e in fopen_temporary_label src/basic/fileio-label.c:63 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#5 0x56197c4a1766 in make_backup src/sysusers/sysusers.c:209 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#6 0x56197c4a6335 in write_files src/sysusers/sysusers.c:710 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#7 0x56197c4ae571 in main src/sysusers/sysusers.c:1817 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#8 0x7f3564dee730 in __libc_start_main (/lib64/libc.so.6+0x20730)
globin
pushed a commit
to mayflower/systemd
that referenced
this pull request
Mar 30, 2017
bash-4.3# journalctl --no-hostname >/dev/null
=================================================================
==288==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 48492 byte(s) in 2694 object(s) allocated from:
#0 0x7fb4aba13e60 in malloc (/lib64/libasan.so.3+0xc6e60)
NixOS#1 0x7fb4ab5b2cc4 in malloc_multiply src/basic/alloc-util.h:70
NixOS#2 0x7fb4ab5b3194 in parse_field src/shared/logs-show.c:98
NixOS#3 0x7fb4ab5b4918 in output_short src/shared/logs-show.c:347
NixOS#4 0x7fb4ab5b7cb7 in output_journal src/shared/logs-show.c:977
NixOS#5 0x5650e29cd83d in main src/journal/journalctl.c:2581
NixOS#6 0x7fb4aabdb730 in __libc_start_main (/lib64/libc.so.6+0x20730)
SUMMARY: AddressSanitizer: 48492 byte(s) leaked in 2694 allocation(s).
Closes: systemd#4568
globin
pushed a commit
to mayflower/systemd
that referenced
this pull request
Mar 30, 2017
"%d (%m) %s\n" crashes asan: google/sanitizers#759 So, let's place %m after %s Fixes: ``` $ ./libtool --mode=execute ./test-selinux ... ============ test_misc ========== ASAN:DEADLYSIGNAL ================================================================= ==2981==ERROR: AddressSanitizer: SEGV on unknown address 0x000041b58ab3 (pc 0x7fd9c55a0eb2 bp 0x7fffdc2f9640 sp 0x7fffdc2f8d68 T0) #0 0x7fd9c55a0eb1 (/lib64/libasan.so.3+0xdeeb1) NixOS#1 0x7fd9c5550bbf (/lib64/libasan.so.3+0x8ebbf) NixOS#2 0x7fd9c5552cdd in __interceptor_vsnprintf (/lib64/libasan.so.3+0x90cdd) NixOS#3 0x7fd9c5063715 in log_internalv src/basic/log.c:680 NixOS#4 0x7fd9c506390a in log_internal src/basic/log.c:697 NixOS#5 0x561d398181a2 in test_misc src/test/test-selinux.c:81 NixOS#6 0x561d398185e8 in main src/test/test-selinux.c:117 NixOS#7 0x7fd9c493a400 in __libc_start_main (/lib64/libc.so.6+0x20400) NixOS#8 0x561d39817859 in _start (/home/vagrant/systemd-asan/.libs/lt-test-selinux+0x1859) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libasan.so.3+0xdeeb1) ==2981==ABORTING ```
globin
pushed a commit
to mayflower/systemd
that referenced
this pull request
Mar 30, 2017
Fixes:
```
touch hola.service
systemctl link $(pwd)/hola.service $(pwd)/hola.service
```
```
==1==ERROR: AddressSanitizer: attempting double-free on 0x60300002c560 in thread T0 (systemd):
#0 0x7fc8c961cb00 in free (/lib64/libasan.so.3+0xc6b00)
NixOS#1 0x7fc8c90ebd3b in strv_clear src/basic/strv.c:83
NixOS#2 0x7fc8c90ebdb6 in strv_free src/basic/strv.c:89
NixOS#3 0x55637c758c77 in strv_freep src/basic/strv.h:37
NixOS#4 0x55637c763ba9 in method_enable_unit_files_generic src/core/dbus-manager.c:1960
NixOS#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
NixOS#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
NixOS#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
NixOS#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
NixOS#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
NixOS#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
NixOS#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
NixOS#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
NixOS#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
NixOS#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
NixOS#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
NixOS#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
NixOS#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
NixOS#18 0x55637c6a2194 in main src/core/main.c:1920
NixOS#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
NixOS#20 0x55637c697339 in _start (/usr/lib/systemd/systemd+0xcd339)
0x60300002c560 is located 0 bytes inside of 19-byte region [0x60300002c560,0x60300002c573)
freed by thread T0 (systemd) here:
#0 0x7fc8c961cb00 in free (/lib64/libasan.so.3+0xc6b00)
NixOS#1 0x7fc8c90ee320 in strv_remove src/basic/strv.c:630
NixOS#2 0x7fc8c90ee190 in strv_uniq src/basic/strv.c:602
NixOS#3 0x7fc8c9180533 in unit_file_link src/shared/install.c:1996
NixOS#4 0x55637c763b25 in method_enable_unit_files_generic src/core/dbus-manager.c:1985
NixOS#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
NixOS#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
NixOS#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
NixOS#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
NixOS#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
NixOS#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
NixOS#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
NixOS#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
NixOS#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
NixOS#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
NixOS#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
NixOS#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
NixOS#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
NixOS#18 0x55637c6a2194 in main src/core/main.c:1920
NixOS#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
previously allocated by thread T0 (systemd) here:
#0 0x7fc8c95b0160 in strdup (/lib64/libasan.so.3+0x5a160)
NixOS#1 0x7fc8c90edf32 in strv_extend src/basic/strv.c:552
NixOS#2 0x7fc8c923ae41 in bus_message_read_strv_extend src/libsystemd/sd-bus/bus-message.c:5578
NixOS#3 0x7fc8c923b0de in sd_bus_message_read_strv src/libsystemd/sd-bus/bus-message.c:5600
NixOS#4 0x55637c7639d1 in method_enable_unit_files_generic src/core/dbus-manager.c:1969
NixOS#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
NixOS#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
NixOS#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
NixOS#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
NixOS#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
NixOS#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
NixOS#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
NixOS#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
NixOS#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
NixOS#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
NixOS#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
NixOS#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
NixOS#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
NixOS#18 0x55637c6a2194 in main src/core/main.c:1920
NixOS#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
SUMMARY: AddressSanitizer: double-free (/lib64/libasan.so.3+0xc6b00) in free
==1==ABORTING
```
Closes systemd#5015
globin
pushed a commit
to mayflower/systemd
that referenced
this pull request
Mar 30, 2017
The simplest way to reproduce: ```diff diff --git a/src/libsystemd-network/test-dhcp6-client.c b/src/libsystemd-network/test-dhcp6-client.c index bd289fa..7b0a5ef 100644 --- a/src/libsystemd-network/test-dhcp6-client.c +++ b/src/libsystemd-network/test-dhcp6-client.c @@ -168,7 +168,7 @@ static uint8_t msg_advertise[198] = { 0x00, 0x17, 0x00, 0x10, 0x20, 0x01, 0x0d, 0xb8, 0xde, 0xad, 0xbe, 0xef, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x18, 0x00, 0x0b, - 0x03, 0x6c, 0x61, 0x62, 0x05, 0x69, 0x6e, 0x74, + 0x01, 0x6c, 0x01, 0x62, 0x00, 0x0a, 0x6e, 0x74, 0x72, 0x61, 0x00, 0x00, 0x1f, 0x00, 0x10, 0x20, 0x01, 0x0d, 0xb8, 0xde, 0xad, 0xbe, 0xef, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, @@ -338,9 +338,7 @@ static int test_advertise_option(sd_event *e) { assert_se(!memcmp(addrs, &msg_advertise[124], r * 16)); r = sd_dhcp6_lease_get_domains(lease, &domains); - assert_se(r == 1); - assert_se(!strcmp("lab.intra", domains[0])); - assert_se(domains[1] == NULL); + assert_se(r == -ENOENT); r = sd_dhcp6_lease_get_ntp_addrs(lease, &addrs); assert_se(r == 1); ``` Fixes: ``` ================================================================= ==15043==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f13c8564160 in strdup (/lib64/libasan.so.3+0x5a160) NixOS#1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 NixOS#2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 NixOS#3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 NixOS#4 0x55f775774b95 in test_advertise_option src/libsystemd-network/test-dhcp6-client.c:287 NixOS#5 0x55f77577883e in main src/libsystemd-network/test-dhcp6-client.c:759 NixOS#6 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f13c8564160 in strdup (/lib64/libasan.so.3+0x5a160) NixOS#1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 NixOS#2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 NixOS#3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 NixOS#4 0x55f775781348 in client_parse_message src/libsystemd-network/sd-dhcp6-client.c:807 NixOS#5 0x55f775781ba2 in client_receive_advertise src/libsystemd-network/sd-dhcp6-client.c:895 NixOS#6 0x55f775782453 in client_receive_message src/libsystemd-network/sd-dhcp6-client.c:994 NixOS#7 0x7f13c7e447f4 in source_dispatch src/libsystemd/sd-event/sd-event.c:2268 NixOS#8 0x7f13c7e471b0 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627 NixOS#9 0x7f13c7e47ab3 in sd_event_run src/libsystemd/sd-event/sd-event.c:2686 NixOS#10 0x7f13c7e47c21 in sd_event_loop src/libsystemd/sd-event/sd-event.c:2706 NixOS#11 0x55f77577863c in test_client_solicit src/libsystemd-network/test-dhcp6-client.c:737 NixOS#12 0x55f77577884b in main src/libsystemd-network/test-dhcp6-client.c:760 NixOS#13 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) SUMMARY: AddressSanitizer: 8 byte(s) leaked in 2 allocation(s). ```
globin
pushed a commit
to mayflower/systemd
that referenced
this pull request
Mar 30, 2017
The simplest way to reproduce: ```diff diff --git a/src/libsystemd-network/test-dhcp6-client.c b/src/libsystemd-network/test-dhcp6-client.c index bd289fa..4e14d8f 100644 --- a/src/libsystemd-network/test-dhcp6-client.c +++ b/src/libsystemd-network/test-dhcp6-client.c @@ -286,6 +286,8 @@ static int test_advertise_option(sd_event *e) { assert_se(optlen == 11); assert_se(dhcp6_lease_set_domains(lease, optval, optlen) >= 0); + assert_se(dhcp6_lease_set_domains(lease, optval, + optlen) >= 0); break; case SD_DHCP6_OPTION_SNTP_SERVERS: ``` Fixes: ``` ==27369==ERROR: LeakSanitizer: detected memory leaks Direct leak of 10 byte(s) in 1 object(s) allocated from: #0 0x7f90e7d21160 in strdup (/lib64/libasan.so.3+0x5a160) NixOS#1 0x7f90e7467f69 in strv_extend src/basic/strv.c:552 NixOS#2 0x5612fcc19379 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 NixOS#3 0x5612fcc1acdf in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 NixOS#4 0x5612fcc06b95 in test_advertise_option src/libsystemd-network/test-dhcp6-client.c:287 NixOS#5 0x5612fcc0a987 in main src/libsystemd-network/test-dhcp6-client.c:761 NixOS#6 0x7f90e6d46400 in __libc_start_main (/lib64/libc.so.6+0x20400) SUMMARY: AddressSanitizer: 10 byte(s) leaked in 1 allocation(s). ```
globin
pushed a commit
to mayflower/systemd
that referenced
this pull request
Mar 30, 2017
We would only log a terse message when pid1 or systemd-journald crashed. It seems better to reuse the normal code paths as much as possible, with the following differences: - if pid1 crashes, we cannot launch the helper, so we don't analyze the coredump, just write it to file directly from the helper invoked by the kernel; - if journald crashes, we can produce the backtrace, but we don't log full structured messages. With comparison to previous code, advantages are: - we go through most of the steps, so for example vacuuming is performed, - we gather and log more data. In particular for journald and pid1 crashes we generate a backtrace, and for pid1 crashes we record the metadata (fdinfo, maps, etc.), - coredumpctl shows pid1 crashes. A disavantage (inefficiency) is that we gather metadata for journald crashes which is then ignored because _TRANSPORT=kernel does not support structued messages. Messages for the systemd-journald "crash" have _TRANSPORT=kernel, and _TRANSPORT=journal for the pid1 "crash". Feb 26 16:27:55 systemd[1]: systemd-journald.service: Main process exited, code=dumped, status=11/SEGV Feb 26 16:27:55 systemd[1]: systemd-journald.service: Unit entered failed state. Feb 26 16:37:54 systemd-coredump[18801]: Process 18729 (systemd-journal) of user 0 dumped core. Feb 26 16:37:54 systemd-coredump[18801]: Coredump diverted to /var/lib/systemd/coredump/core.systemd-journal.0.36c14bf3c6ce4c38914f441038990979.18729.1488145074000000.lz4 Feb 26 16:37:54 systemd-coredump[18801]: Stack trace of thread 18729: Feb 26 16:37:54 systemd-coredump[18801]: #0 0x00007f46d6a06b8d fsync (libpthread.so.0) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#1 0x00007f46d71bfc47 journal_file_set_online (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#2 0x00007f46d71c1c31 journal_file_append_object (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#3 0x00007f46d71c3405 journal_file_append_data (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#4 0x00007f46d71c4b7c journal_file_append_entry (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#5 0x00005577688cf056 write_to_journal (systemd-journald) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#6 0x00005577688d2e98 dispatch_message_real (systemd-journald) Feb 26 16:37:54 kernel: systemd-coredum: 9 output lines suppressed due to ratelimiting Feb 26 16:37:54 systemd-journald[18810]: Journal started Feb 26 16:50:59 systemd-coredump[19229]: Due to PID 1 having crashed coredump collection will now be turned off. Feb 26 16:51:00 systemd[1]: Caught <SEGV>, dumped core as pid 19228. Feb 26 16:51:00 systemd[1]: Freezing execution. Feb 26 16:51:00 systemd-coredump[19229]: Process 19228 (systemd) of user 0 dumped core. Stack trace of thread 19228: #0 0x00007fab82075c47 kill (libc.so.6) NixOS#1 0x000055fdf7c38b6b crash (systemd) NixOS#2 0x00007fab824175c0 __restore_rt (libpthread.so.0) NixOS#3 0x00007fab82148573 epoll_wait (libc.so.6) NixOS#4 0x00007fab8366f84a sd_event_wait (libsystemd-shared-233.so) NixOS#5 0x00007fab836701de sd_event_run (libsystemd-shared-233.so) NixOS#6 0x000055fdf7c4a380 manager_loop (systemd) NixOS#7 0x000055fdf7c402c2 main (systemd) NixOS#8 0x00007fab82060401 __libc_start_main (libc.so.6) NixOS#9 0x000055fdf7c3818a _start (systemd) Poor machine ;)
fpletz
pushed a commit
to mayflower/systemd
that referenced
this pull request
Feb 11, 2018
In general we'd leak anything that was allocated in the first parsing of
netdev, e.g. netdev name, host name, etc. Use normal netdev_unref to make sure
everything is freed.
--- command ---
/home/zbyszek/src/systemd/build2/test-network
--- stderr ---
/etc/systemd/network/wg0.netdev:3: Failed to parse netdev kind, ignoring: wireguard
/etc/systemd/network/wg0.netdev:5: Unknown section 'WireGuard'. Ignoring.
/etc/systemd/network/wg0.netdev:9: Unknown section 'WireGuardPeer'. Ignoring.
NetDev has no Kind configured in /etc/systemd/network/wg0.netdev. Ignoring
/etc/systemd/network/br0.network:13: Unknown lvalue 'NetDev' in section 'Network'
br0: netdev ready
=================================================================
==11666==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7f3a314cf238 in __interceptor_strdup (/lib64/libasan.so.4+0x77238)
NixOS#1 0x7f3a30e71ad1 in free_and_strdup ../src/basic/string-util.c:870
NixOS#2 0x7f3a30d34fba in config_parse_ifname ../src/shared/conf-parser.c:981
NixOS#3 0x7f3a30d2f5b0 in next_assignment ../src/shared/conf-parser.c:155
NixOS#4 0x7f3a30d30303 in parse_line ../src/shared/conf-parser.c:273
NixOS#5 0x7f3a30d30dee in config_parse ../src/shared/conf-parser.c:390
NixOS#6 0x7f3a30d310a5 in config_parse_many_files ../src/shared/conf-parser.c:428
NixOS#7 0x7f3a30d3181c in config_parse_many ../src/shared/conf-parser.c:487
NixOS#8 0x55b4200f9b00 in netdev_load_one ../src/network/netdev/netdev.c:634
NixOS#9 0x55b4200fb562 in netdev_load ../src/network/netdev/netdev.c:778
NixOS#10 0x55b4200c607a in manager_load_config ../src/network/networkd-manager.c:1299
NixOS#11 0x55b4200818e0 in test_load_config ../src/network/test-network.c:128
NixOS#12 0x55b42008343b in main ../src/network/test-network.c:254
NixOS#13 0x7f3a305f8889 in __libc_start_main (/lib64/libc.so.6+0x20889)
SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
-------
fpletz
pushed a commit
that referenced
this pull request
Aug 3, 2018
Some versions of asan report the following false positive
when strict_string_checks=1 is passed:
=================================================================
==3297==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f64e4090286 bp 0x7ffe46acd9a0 sp 0x7ffe46acd118 T0)
==3297==The signal is caused by a READ memory access.
==3297==Hint: address points to the zero page.
#0 0x7f64e4090285 in __strlen_sse2 (/lib64/libc.so.6+0xaa285)
#1 0x7f64e5a51e46 (/lib64/libasan.so.4+0x41e46)
#2 0x7f64e4e5e3a0 (/lib64/libglib-2.0.so.0+0x383a0)
#3 0x7f64e4e5e536 in g_dgettext (/lib64/libglib-2.0.so.0+0x38536)
#4 0x7f64e48fac5f (/lib64/libgio-2.0.so.0+0xc1c5f)
#5 0x7f64e4c03978 in g_type_class_ref (/lib64/libgobject-2.0.so.0+0x30978)
#6 0x7f64e4be9567 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x16567)
#7 0x7f64e4be9fd0 in g_object_new (/lib64/libgobject-2.0.so.0+0x16fd0)
#8 0x7f64e48fd43e in g_dbus_message_new_from_blob (/lib64/libgio-2.0.so.0+0xc443e)
#9 0x564a6aa0de52 in main ../src/libsystemd/sd-bus/test-bus-marshal.c:228
#10 0x7f64e4007009 in __libc_start_main (/lib64/libc.so.6+0x21009)
#11 0x564a6aa0a569 in _start (/home/vagrant/systemd/build/test-bus-marshal+0x5569)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0xaa285) in __strlen_sse2
==3297==ABORTING
It's an external library and errors in external libraries are generally not very
useful for looking for internal bugs.
It would be better not to change the code and use standard suppression
techinques decribed at
https://clang.llvm.org/docs/AddressSanitizer.html#suppressing-reports-in-external-libraries,
but, unfortunaley, none of them seems to be able to suppress fatal errors in asan intself.
fpletz
pushed a commit
that referenced
this pull request
Aug 3, 2018
Fuzzing with AddressSanitizer reports an error here:
==11==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7fe53f5497d8 at pc 0x7fe53ef055c9 bp 0x7ffd344e9380 sp 0x7ffd344e9378
READ of size 4 at 0x7fe53f5497d8 thread T0
SCARINESS: 27 (4-byte-read-global-buffer-overflow-far-from-bounds)
#0 0x7fe53ef055c8 in bus_error_name_to_errno /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:118:24
#1 0x7fe53ef0577b in bus_error_setfv /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:274:17
#2 0x7fe53ef0595a in sd_bus_error_setf /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:284:21
#3 0x561059 in manager_load_unit_prepare /work/build/../../src/systemd/src/core/manager.c
#4 0x560680 in manager_load_unit /work/build/../../src/systemd/src/core/manager.c:1773:13
#5 0x5d49a6 in unit_add_dependency_by_name /work/build/../../src/systemd/src/core/unit.c:2882:13
#6 0x538996 in config_parse_unit_deps /work/build/../../src/systemd/src/core/load-fragment.c:152:21
#7 0x6db771 in next_assignment /work/build/../../src/systemd/src/shared/conf-parser.c:155:32
#8 0x6d697e in parse_line /work/build/../../src/systemd/src/shared/conf-parser.c:273:16
#9 0x6d5c48 in config_parse /work/build/../../src/systemd/src/shared/conf-parser.c:390:21
#10 0x535678 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-unit-file.c:41:16
#11 0x73bd60 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:517:13
#12 0x73a39f in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:442:3
#13 0x73d9bc in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:650:19
#14 0x73fa05 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:773:5
#15 0x71f75d in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:754:6
#16 0x71285c in main /src/libfuzzer/FuzzerMain.cpp:20:10
#17 0x7fe53da0482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#18 0x430e68 in _start (/out/fuzz-unit-file+0x430e68)
0x7fe53f5497d8 is located 8 bytes to the right of global variable 'bus_common_errors' defined in '../../src/systemd/src/libsystemd/sd-bus/bus-common-errors.c:28:51' (0x7fe53f549300) of size 1232
SUMMARY: AddressSanitizer: global-buffer-overflow /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:118:24 in bus_error_name_to_errno
Shadow bytes around the buggy address:
0x0ffd27ea12a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea12b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea12c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea12d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea12e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ffd27ea12f0: 00 00 00 00 00 00 00 00 00 00 f9[f9]f9 f9 f9 f9
0x0ffd27ea1300: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x0ffd27ea1310: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x0ffd27ea1320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea1330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea1340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==11==ABORTING
but I think it's a false positive because of our low-level magic in how this
area is constructed.
fpletz
pushed a commit
that referenced
this pull request
Aug 3, 2018
`fuzz-journal-remote` seems to be failing under `msan` as soon as it starts:
$ sudo infra/helper.py run_fuzzer systemd fuzz-journal-remote
Running: docker run --rm -i --privileged -e FUZZING_ENGINE=libfuzzer -v /home/vagrant/oss-fuzz/build/out/systemd:/out -t gcr.io/oss-fuzz-base/base-runner run_fuzzer fuzz-journal-remote
Using seed corpus: fuzz-journal-remote_seed_corpus.zip
/out/fuzz-journal-remote -rss_limit_mb=2048 -timeout=25 /tmp/fuzz-journal-remote_corpus -max_len=65536 < /dev/null
INFO: Seed: 3380449479
INFO: Loaded 2 modules (36336 inline 8-bit counters): 36139 [0x7ff36ea31d39, 0x7ff36ea3aa64), 197 [0x9998c8, 0x99998d),
INFO: Loaded 2 PC tables (36336 PCs): 36139 [0x7ff36ea3aa68,0x7ff36eac7d18), 197 [0x999990,0x99a5e0),
INFO: 2 files found in /tmp/fuzz-journal-remote_corpus
INFO: seed corpus: files: 2 min: 4657b max: 7790b total: 12447b rss: 97Mb
Uninitialized bytes in __interceptor_pwrite64 at offset 24 inside [0x7fffdd4d7230, 240)
==15==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7ff36e685e8a in journal_file_init_header /work/build/../../src/systemd/src/journal/journal-file.c:436:13
#1 0x7ff36e683a9d in journal_file_open /work/build/../../src/systemd/src/journal/journal-file.c:3333:21
#2 0x7ff36e68b8f6 in journal_file_open_reliably /work/build/../../src/systemd/src/journal/journal-file.c:3520:13
#3 0x4a3f35 in open_output /work/build/../../src/systemd/src/journal-remote/journal-remote.c:70:13
#4 0x4a34d0 in journal_remote_get_writer /work/build/../../src/systemd/src/journal-remote/journal-remote.c:136:21
#5 0x4a550f in get_source_for_fd /work/build/../../src/systemd/src/journal-remote/journal-remote.c:183:13
#6 0x4a46bd in journal_remote_add_source /work/build/../../src/systemd/src/journal-remote/journal-remote.c:235:13
#7 0x4a271c in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journal-remote.c:36:9
#8 0x4f27cc in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:524:13
#9 0x4efa0b in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:448:3
#10 0x4f8e96 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:732:7
#11 0x4f9f73 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:752:3
#12 0x4bf329 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:756:6
#13 0x4ac391 in main /src/libfuzzer/FuzzerMain.cpp:20:10
#14 0x7ff36d14982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#15 0x41f9d8 in _start (/out/fuzz-journal-remote+0x41f9d8)
Uninitialized value was stored to memory at
#0 0x7ff36e61cd41 in sd_id128_randomize /work/build/../../src/systemd/src/libsystemd/sd-id128/sd-id128.c:288:16
#1 0x7ff36e685cec in journal_file_init_header /work/build/../../src/systemd/src/journal/journal-file.c:426:13
#2 0x7ff36e683a9d in journal_file_open /work/build/../../src/systemd/src/journal/journal-file.c:3333:21
#3 0x7ff36e68b8f6 in journal_file_open_reliably /work/build/../../src/systemd/src/journal/journal-file.c:3520:13
#4 0x4a3f35 in open_output /work/build/../../src/systemd/src/journal-remote/journal-remote.c:70:13
#5 0x4a34d0 in journal_remote_get_writer /work/build/../../src/systemd/src/journal-remote/journal-remote.c:136:21
#6 0x4a550f in get_source_for_fd /work/build/../../src/systemd/src/journal-remote/journal-remote.c:183:13
#7 0x4a46bd in journal_remote_add_source /work/build/../../src/systemd/src/journal-remote/journal-remote.c:235:13
#8 0x4a271c in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journal-remote.c:36:9
#9 0x4f27cc in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:524:13
#10 0x4efa0b in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:448:3
#11 0x4f8e96 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:732:7
#12 0x4f9f73 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:752:3
#13 0x4bf329 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:756:6
#14 0x4ac391 in main /src/libfuzzer/FuzzerMain.cpp:20:10
#15 0x7ff36d14982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
Uninitialized value was created by an allocation of 't' in the stack frame of function 'sd_id128_randomize'
#0 0x7ff36e61cb00 in sd_id128_randomize /work/build/../../src/systemd/src/libsystemd/sd-id128/sd-id128.c:274
SUMMARY: MemorySanitizer: use-of-uninitialized-value /work/build/../../src/systemd/src/journal/journal-file.c:436:13 in journal_file_init_header
Exiting
MS: 0 ; base unit: 0000000000000000000000000000000000000000
artifact_prefix='./'; Test unit written to ./crash-847911777b3096783f4ee70a69ab6d28380c810b
[vagrant@localhost oss-fuzz]$ sudo infra/helper.py check_build --sanitizer=memory systemd
Running: docker run --rm -i --privileged -e FUZZING_ENGINE=libfuzzer -e SANITIZER=memory -v /home/vagrant/oss-fuzz/build/out/systemd:/out -t gcr.io/oss-fuzz-base/base-runner test_all
INFO: performing bad build checks for /out/fuzz-dhcp-server.
INFO: performing bad build checks for /out/fuzz-journal-remote.
INFO: performing bad build checks for /out/fuzz-unit-file.
INFO: performing bad build checks for /out/fuzz-dns-packet.
4 fuzzers total, 0 seem to be broken (0%).
Check build passed.
It's a false positive which is most likely caused by
google/sanitizers#852. I think it could be got around
by avoiding `getrandom` when the code is compiled with `msan`
Mic92
pushed a commit
that referenced
this pull request
Feb 22, 2019
This function returns 0 on success and a negative value on failure. On success,
it writes the parsed action to the address passed in its third argument.
`bus_set_transient_emergency_action` does this:
r = parse_emergency_action(s, system, &v);
if (v < 0)
// handle failure
However, `v` is not updated if the function fails, and this should be checking
`r` instead of `v`.
The result of this is that if an invalid failure (or success) action is
specified, systemd ends up creating the unit anyway and then misbehaves if it
tries to run the failure action because the action value comes from
uninitialized stack data. In my case, this resulted in a failed assertion:
Program received signal SIGABRT, Aborted.
0x00007fe52cca0d7f in raise () from /snap/usr/lib/libc.so.6
(gdb) bt
#0 0x00007fe52cca0d7f in raise () from /snap/usr/lib/libc.so.6
#1 0x00007fe52cc8b672 in abort () from /snap/usr/lib/libc.so.6
#2 0x00007fe52d66f169 in log_assert_failed_realm (realm=LOG_REALM_SYSTEMD, text=0x56177ab8e000 "action < _EMERGENCY_ACTION_MAX", file=0x56177ab8dfb8 "../src/core/emergency-action.c", line=33, func=0x56177ab8e2b0 <__PRETTY_FUNCTION__.14207> "emergency_action") at ../src/basic/log.c:795
#3 0x000056177aa98cf4 in emergency_action (m=0x56177c992cb0, action=2059118610, options=(unknown: 0), reboot_arg=0x0, exit_status=1, reason=0x7ffdd2df4290 "unit run-u0.service failed") at ../src/core/emergency-action.c:33
#4 0x000056177ab2b739 in unit_notify (u=0x56177c9eb340, os=UNIT_ACTIVE, ns=UNIT_FAILED, flags=(unknown: 0)) at ../src/core/unit.c:2504
#5 0x000056177aaf62ed in service_set_state (s=0x56177c9eb340, state=SERVICE_FAILED) at ../src/core/service.c:1104
#6 0x000056177aaf8a29 in service_enter_dead (s=0x56177c9eb340, f=SERVICE_SUCCESS, allow_restart=true) at ../src/core/service.c:1712
#7 0x000056177aaf9233 in service_enter_signal (s=0x56177c9eb340, state=SERVICE_FINAL_SIGKILL, f=SERVICE_SUCCESS) at ../src/core/service.c:1854
#8 0x000056177aaf921b in service_enter_signal (s=0x56177c9eb340, state=SERVICE_FINAL_SIGTERM, f=SERVICE_SUCCESS) at ../src/core/service.c:1852
#9 0x000056177aaf8eb3 in service_enter_stop_post (s=0x56177c9eb340, f=SERVICE_SUCCESS) at ../src/core/service.c:1788
#10 0x000056177aaf91eb in service_enter_signal (s=0x56177c9eb340, state=SERVICE_STOP_SIGKILL, f=SERVICE_SUCCESS) at ../src/core/service.c:1850
#11 0x000056177aaf91bc in service_enter_signal (s=0x56177c9eb340, state=SERVICE_STOP_SIGTERM, f=SERVICE_FAILURE_EXIT_CODE) at ../src/core/service.c:1848
#12 0x000056177aaf9759 in service_enter_running (s=0x56177c9eb340, f=SERVICE_FAILURE_EXIT_CODE) at ../src/core/service.c:1941
#13 0x000056177ab005b7 in service_sigchld_event (u=0x56177c9eb340, pid=112, code=1, status=1) at ../src/core/service.c:3296
#14 0x000056177aad84b5 in manager_invoke_sigchld_event (m=0x56177c992cb0, u=0x56177c9eb340, si=0x7ffdd2df48f0) at ../src/core/manager.c:2444
#15 0x000056177aad88df in manager_dispatch_sigchld (source=0x56177c994710, userdata=0x56177c992cb0) at ../src/core/manager.c:2508
#16 0x00007fe52d72f807 in source_dispatch (s=0x56177c994710) at ../src/libsystemd/sd-event/sd-event.c:2846
#17 0x00007fe52d730f7d in sd_event_dispatch (e=0x56177c993530) at ../src/libsystemd/sd-event/sd-event.c:3229
#18 0x00007fe52d73142e in sd_event_run (e=0x56177c993530, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3286
#19 0x000056177aad9f71 in manager_loop (m=0x56177c992cb0) at ../src/core/manager.c:2906
#20 0x000056177aa7c876 in invoke_main_loop (m=0x56177c992cb0, ret_reexecute=0x7ffdd2df4bff, ret_retval=0x7ffdd2df4c04, ret_shutdown_verb=0x7ffdd2df4c58, ret_fds=0x7ffdd2df4c70, ret_switch_root_dir=0x7ffdd2df4c48, ret_switch_root_init=0x7ffdd2df4c50, ret_error_message=0x7ffdd2df4c60) at ../src/core/main.c:1792
#21 0x000056177aa7f251 in main (argc=2, argv=0x7ffdd2df4e78) at ../src/core/main.c:2573
Fix this by checking the correct variable.
andir
pushed a commit
that referenced
this pull request
May 29, 2019
I had a test machine with ulimit -n set to 1073741816 through pam
("session required pam_limits.so set_all", which copies the limits from PID 1,
left over from testing of systemd#10921).
test-execute would "hang" and then fail with a timeout when running
exec-inaccessiblepaths-proc.service. It turns out that the problem was in
close_all_fds(), which would go to the fallback path of doing close()
1073741813 times. Let's just fail if we hit this case. This only matters
for cases where both /proc is inaccessible, and the *soft* limit has been
raised.
(gdb) bt
#0 0x00007f7e2e73fdc8 in close () from target:/lib64/libc.so.6
#1 0x00007f7e2e42cdfd in close_nointr ()
from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
#2 0x00007f7e2e42d525 in close_all_fds ()
from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
#3 0x0000000000426e53 in exec_child ()
#4 0x0000000000429578 in exec_spawn ()
#5 0x00000000004ce1ab in service_spawn ()
#6 0x00000000004cff77 in service_enter_start ()
#7 0x00000000004d028f in service_enter_start_pre ()
#8 0x00000000004d16f2 in service_start ()
#9 0x00000000004568f4 in unit_start ()
#10 0x0000000000416987 in test ()
#11 0x0000000000417632 in test_exec_inaccessiblepaths ()
#12 0x0000000000419362 in run_tests ()
#13 0x0000000000419632 in main ()
andir
pushed a commit
that referenced
this pull request
Sep 7, 2019
We would not send the property because we'd call sd_bus_get_current_message() which would return NULL. If there is no message, we cannot support /self or /auto, but things are still OK if a path with a session name is given. Traceback when the issue is triggered: #2 we'd call sd_bus_get_current_message() here, which would return NULL, and session_object_find() would immediately return 0. #3 0x00000000004289b7 in session_object_find (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x9efda0 "org.freedesktop.login1.Session", userdata=0x9852f0, found=0x7ffe3e975fe8, error=0x7ffe3e9760b0) at ../src/login/logind-session-dbus.c:620 #4 0x00007ff74bfdde39 in node_vtable_get_userdata (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", c=0x9f6d58, userdata=0x7ffe3e976070, error=0x7ffe3e9760b0) at ../src/libsystemd/sd-bus/bus-objects.c:37 #5 0x00007ff74bfe49af in emit_properties_changed_on_interface (bus=0x9f1110, prefix=0xa133a0 "/org/freedesktop/login1/session", path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session", require_fallback=true, found_interface=0x7ffe3e976163, names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2088 #6 0x00007ff74bfe56a4 in sd_bus_emit_properties_changed_strv (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session", names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2291 #7 0x00000000004292ea in session_send_changed (s=0xa16e10, properties=0x43ee27 "Active") at ../src/login/logind-session-dbus.c:730 #8 0x0000000000424cd7 in seat_set_active (s=0x9ee280, session=0xa16e10) at ../src/login/logind-seat.c:249 #9 0x00000000004251cf in seat_active_vt_changed (s=0x9ee280, vtnr=3) at ../src/login/logind-seat.c:361 #10 0x000000000042547b in seat_read_active_vt (s=0x9ee280) at ../src/login/logind-seat.c:395 #11 0x000000000040ab5c in manager_dispatch_console (s=0x9f0320, fd=8, revents=8, userdata=0x9852f0) at ../src/login/logind.c:588 #12 0x00007ff74c042d5f in source_dispatch (s=0x9f0320) at ../src/libsystemd/sd-event/sd-event.c:2828 #13 0x00007ff74c04469f in sd_event_dispatch (e=0x9ef340) at ../src/libsystemd/sd-event/sd-event.c:3241 #14 0x00007ff74c044b58 in sd_event_run (e=0x9ef340, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3299 #15 0x000000000040d7e8 in manager_run (m=0x9852f0) at ../src/login/logind.c:1186 #16 0x000000000040db58 in run (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1234 #17 0x000000000040dc30 in main (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1244 Fixes systemd#13437. Bug introduced in 3b92c08.
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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 reverts commit cbee77f. It's a part of Plymouth-related PRs.