zsh-completion: a more style/tag aware _systemctl#5
Conversation
using _wanted instead of calling compadd directly. this allows the user to customize
possible matches.
An example being, grouping units by type:
autoload -Uz compinit; compinit
zstyle ':completion:*' menu select
zstyle ':completion:*' group-name ''
zstyle ':completion:*' format 'Completing %d'
zstyle -e ':completion:*:*:systemctl-(((re|)en|dis)able|(*re|)start|reload*):*' \
tag-order 'local type; for type in service template target socket;
reply+=( systemd-units:-${type}:${type} ); reply=( "$reply systemd-units:-misc:misc" )'
zstyle ':completion:*:systemd-units-template' ignored-patterns '^*@'
zstyle ':completion:*:systemd-units-target' ignored-patterns '^*.target'
zstyle ':completion:*:systemd-units-socket' ignored-patterns '^*.socket'
zstyle ':completion:*:systemd-units-service' ignored-patterns '^*.service'
zstyle ':completion:*:systemd-units-misc' ignored-patterns '*(@|.(service|socket|target))'
also, <poke> http://lists.freedesktop.org/archives/systemd-devel/2015-May/032012.html
zonque
added a commit
that referenced
this pull request
Jun 2, 2015
…[email protected] zsh-completion: a more style/tag aware _systemctl
msekletar
referenced
this pull request
in msekletar/systemd
Jun 2, 2015
=================================================================
==64281==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f623c961c4a in malloc (/usr/lib64/libasan.so.2+0x96c4a)
#1 0x5651f79ad34e in malloc_multiply (/home/crrodriguez/scm/systemd/systemd-modules-load+0x2134e)
#2 0x5651f79b02d6 in strjoin (/home/crrodriguez/scm/systemd/systemd-modules-load+0x242d6)
#3 0x5651f79be1f5 in files_add (/home/crrodriguez/scm/systemd/systemd-modules-load+0x321f5)
#4 0x5651f79be6a3 in conf_files_list_strv_internal (/home/crrodriguez/scm/systemd/systemd-modules-load+0x326a3)
#5 0x5651f79bea24 in conf_files_list_nulstr (/home/crrodriguez/scm/systemd/systemd-modules-load+0x32a24)
#6 0x5651f79ad01a in main (/home/crrodriguez/scm/systemd/systemd-modules-load+0x2101a)
#7 0x7f623c11586f in __libc_start_main (/lib64/libc.so.6+0x2086f)
SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).
This happens due to the wrong cleanup attribute is used (free vs strv_free)
msekletar
referenced
this pull request
in msekletar/systemd
Jun 2, 2015
If systemd is built with GCC address sanitizer or leak sanitizer the following memory leak ocurs: May 12 02:02:46 linux.site systemd[326]: ================================================================= May 12 02:02:46 linux.site systemd[326]: ==326==ERROR: LeakSanitizer: detected memory leaks May 12 02:02:46 linux.site systemd[326]: Direct leak of 101 byte(s) in 3 object(s) allocated from: May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup (/usr/lib64/libasan.so.2+0x6293f) May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5336 in strv_new_ap src/shared/strv.c:163 May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new src/shared/strv.c:185 May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths src/shared/path-lookup.c:223 May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in manager_run_generators src/core/manager.c:2828 May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup src/core/manager.c:1121 May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main src/core/main.c:1667 May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) May 12 02:02:46 linux.site systemd[326]: Direct leak of 29 byte(s) in 1 object(s) allocated from: May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup (/usr/lib64/libasan.so.2+0x6293f) May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5288 in strv_new_ap src/shared/strv.c:152 May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new src/shared/strv.c:185 May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths src/shared/path-lookup.c:223 May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in manager_run_generators src/core/manager.c:2828 May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup src/core/manager.c:1121 May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main src/core/main.c:1667 May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main (/lib64/libc.so.6+0x208c4) May 12 02:02:46 linux.site systemd[326]: SUMMARY: AddressSanitizer: 130 byte(s) leaked in 4 allocation(s). There is a leak due to the the use of cleanup_free instead _cleanup_strv_free_
msekletar
referenced
this pull request
in msekletar/systemd
Jun 2, 2015
$ /usr/lib/systemd/systemd-timedated (wait until auto-exit)
=================================================================
==396==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 928 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
#1 0x562a83ae60cf in bus_message_from_header src/libsystemd/sd-bus/bus-message.c:480
#2 0x562a83ae6f5a in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:576
#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#9 0x562a83aae1af in main src/timedate/timedated.c:730
#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 77 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a)
#1 0x562a83ad418a in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:963
#2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#4 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
#5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#6 0x562a83aae1af in main src/timedate/timedated.c:730
#7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f)
#1 0x562a83b0229b in bus_message_parse_fields src/libsystemd/sd-bus/bus-message.c:5382
#2 0x562a83ae7290 in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:601
#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#9 0x562a83aae1af in main src/timedate/timedated.c:730
#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s).
This is due to missing _cleanup_bus_message_unref_ in context_read_ntp()
This was referenced Jun 8, 2015
dvdhrm
pushed a commit
to dvdhrm/systemd
that referenced
this pull request
Jun 16, 2015
Make sure we never close fds before we drop their related event-source. This will cause horrible disruptions if the fd-num is re-used by someone else. Under normal conditions, this should not cause any problems as the close() will drop the fd from the epoll-set automatically. However, this changes if you have any child processes with a copy of that fd. This fixes issue systemd#163. Background: If you create an epoll-set via epoll_create() (lets call it 'EFD') you can add file-descriptors to it to watch for events. Whenever you call EPOLL_CTL_ADD on a file-descriptor you want to watch, the kernel looks up the attached "struct file" pointer, that this FD refers to. This combination of the FD-number and the "struct file" pointer is used as key to link it into the epoll-set (EFD). This means, if you duplicate your file-descriptor, you can watch this file-descriptor, too (because the duplicate will have a different FD-number, hence, the combination of FD-number and "struct file" is different as before). If you want to stop watching an FD, you use EPOLL_CTL_DEL and pass the FD to the kernel. The kernel again looks up your file-descriptor in your FD-table to find the linked "struct file". This FD-number and "struct file" combination is then dropped from the epoll-set (EFD). Last, but not least: If you close a file-descriptor that is linked to an epoll-set, the kernel does *NOTHING* regarding the epoll-set. This is a vital observation! Because this means, your epoll_wait() calls will still return the metadata you used to watch/subscribe your file-descriptor to events. There is one exception to this rule: If the file-descriptor that you just close()ed was the last FD that referred to the underlying "struct file", then _all_ epoll-set watches/subscriptions are destroyed. Hence, if you never dup()ed your FD, then a simple close() will also unsubscribe it from any epoll-set. With this in mind, lets look at fork(): Assume you have an epoll-set (EFD) and a bunch of FDs subscribed to events on that EFD. If you now call fork(), the new process gets a copy of your file-descriptor table. This means, the whole table is copied and the "struct file" reference of each FD is increased by 1. It is important to notice that the FD-numbers in the child are exactly the same as in the parent (eg., FD systemd#5 in the child refers to the same "struct file" as FD systemd#5 in the parent). This means, if the child calls EPOLL_CTL_DEL on an FD, the kernel will look up the linked "struct file" and drop the FD-number and "struct file" combination from the epoll-set (EFD). However, this will effectively drop the subscription that was installed by the parent. To sum up: even though the child gets a duplicate of the EFD and all FDs, the subscriptions in the EFD are *NOT* duplicated! Now, with this in mind, lets look at what udevd does: Udevd has a bunch of file-descriptors that it watches in its sd-event main-loop. Whenever a uevent is received, the event is dispatched on its workers. If no suitable worker is present, a new worker is fork()ed to handle the event. Inside of this worker, we try to free all resources we inherited. However, the fork() call is done from a call-stack that is never rewinded. Therefore, this call stack might own references that it drops once it is left. Those references we cannot deduce from the fork()'ed process; effectively causing us to leak objects in the worker (eg., the call to sd_event_dispatch() that dispatched our uevent owns a reference to the sd_event object it used; and drops it again once the function is left). (Another example is udev_monitor_ref() for each 'worker' that is also inherited by all children; thus keeping the udev-monitor and the uevent-fd alive in all children (which is the real cause for bug systemd#163)) (The extreme variant is sd_event_source_unref(), which explicitly keeps event-sources alive, if they're currently dispatched, knowing that the dispatcher will free the event once done. But if the dispatcher is in the parent, the child will never ever free that object, thus leaking it) This is usually not an issue. However, if such an object has a file-descriptor embedded, this FD is left open and never closed in the child. In manager_exit(), if we now destroy an object (i.e., close its embedded file-descriptor) before we destroy its related sd_event_source, then sd-event will not be able to drop the FD from the epoll-set (EFD). This is, because the FD is no longer valid at the time we call EPOLL_CTL_DEL. Hence, the kernel cannot figure out the linked "struct file" and thus cannot remove the FD-number plus "struct file" combination; effectively leaving the subscription in the epoll-set. Since we leak the uevent-fd in the children, they retain a copy of the FD pointing to the same "struct file". Thus, the EFD-subscription are not automatically removed by close() (as described above). Therefore, the main daemon will still get its metadata back on epoll_watch() whenever an event occurs (even though it already freed the metadata). This then causes the free-after-use bug described in systemd#163. This patch fixes the order in which we destruct objects and related sd-event-sources. Some open questions remain: * Why does source_io_unregister() not warn on EPOLL_CTL_DEL failures? This really needs to be turned into an assert_return(). * udevd really should not leak file-descriptors into its children. Fixing this would *not* have prevented this bug, though (since the child-setup is still async). It's non-trivial to fix this, though. The stack-context of the caller cannot be rewinded, so we cannot figure out temporary refs. Maybe it's time to exec() the udev-workers? * Why does the kernel not copy FD-subscriptions across fork()? Or at least drop subscriptions if you close() your FD (it uses the FD-number as key, so it better subscribe to it)? Or it better used FD+"struct file_table*"+"struct file*" as key to not allow the childen to share the subscription table.. *sigh* Seems like we have to live with that API forever.
whot
pushed a commit
to whot/systemd
that referenced
this pull request
Jul 30, 2015
$ /usr/lib/systemd/systemd-timedated (wait until auto-exit)
=================================================================
==396==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 928 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
systemd#1 0x562a83ae60cf in bus_message_from_header src/libsystemd/sd-bus/bus-message.c:480
systemd#2 0x562a83ae6f5a in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:576
systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 77 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a)
systemd#1 0x562a83ad418a in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:963
systemd#2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#4 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#6 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f)
systemd#1 0x562a83b0229b in bus_message_parse_fields src/libsystemd/sd-bus/bus-message.c:5382
systemd#2 0x562a83ae7290 in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:601
systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s).
This is due to missing _cleanup_bus_message_unref_ in context_read_ntp()
(cherry picked from commit 6b71bab)
Closed
Closed
evverx
referenced
this pull request
in evverx/systemd
Mar 14, 2016
Fixes:
Message: Process 806 (systemd-importd) of user 0 dumped core.
Stack trace of thread 806:
#0 0x00007f5eaeff7227 raise (libc.so.6)
#1 0x00007f5eaeff8e8a abort (libc.so.6)
#2 0x000055b6d3418f4f log_assert_failed (systemd-importd)
#3 0x000055b6d3409daf safe_close (systemd-importd)
#4 0x000055b6d33c25ea closep (systemd-importd)
#5 0x000055b6d33c38d9 setup_machine_directory (systemd-importd)
#6 0x000055b6d33b8536 method_pull_tar_or_raw (systemd-importd)
#7 0x000055b6d33ed097 method_callbacks_run (systemd-importd)
#8 0x000055b6d33ef929 object_find_and_run (systemd-importd)
#9 0x000055b6d33eff6b bus_process_object (systemd-importd)
#10 0x000055b6d3447f77 process_message (systemd-importd)
#11 0x000055b6d344815a process_running (systemd-importd)
#12 0x000055b6d3448a10 bus_process_internal (systemd-importd)
#13 0x000055b6d3448ae1 sd_bus_process (systemd-importd)
#14 0x000055b6d3449779 time_callback (systemd-importd)
#15 0x000055b6d3454ff4 source_dispatch (systemd-importd)
#16 0x000055b6d34562b9 sd_event_dispatch (systemd-importd)
#17 0x000055b6d34566f8 sd_event_run (systemd-importd)
#18 0x000055b6d33ba72a bus_event_loop_with_idle (systemd-importd)
#19 0x000055b6d33b95bc manager_run (systemd-importd)
#20 0x000055b6d33b9766 main (systemd-importd)
#21 0x00007f5eaefe2a00 __libc_start_main (libc.so.6)
#22 0x000055b6d33b5569 _start (systemd-importd)
lnykryn
pushed a commit
to lnykryn/systemd
that referenced
this pull request
Mar 23, 2016
$ /usr/lib/systemd/systemd-timedated (wait until auto-exit)
=================================================================
==396==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 928 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
systemd#1 0x562a83ae60cf in bus_message_from_header src/libsystemd/sd-bus/bus-message.c:480
systemd#2 0x562a83ae6f5a in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:576
systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 77 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a)
systemd#1 0x562a83ad418a in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:963
systemd#2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#4 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#6 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f)
systemd#1 0x562a83b0229b in bus_message_parse_fields src/libsystemd/sd-bus/bus-message.c:5382
systemd#2 0x562a83ae7290 in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:601
systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s).
This is due to missing _cleanup_bus_message_unref_ in context_read_ntp()
(cherry picked from commit 6b71bab)
Cherry-picked from: 6b71bab
Resolves: #1222517
2 tasks
evverx
referenced
this pull request
in evverx/systemd
Jun 4, 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
keszybz
pushed a commit
that referenced
this pull request
Jun 4, 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
evverx
referenced
this pull request
in evverx/systemd
Oct 21, 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]: #1 0x7f3565526bd0 in malloc_multiply src/basic/alloc-util.h:70 Oct 20 09:10:49 systemd-sysusers[144]: #2 0x7f356552cb55 in tempfn_xxxxxx src/basic/fileio.c:1116 Oct 20 09:10:49 systemd-sysusers[144]: #3 0x7f356552c4f0 in fopen_temporary src/basic/fileio.c:1042 Oct 20 09:10:49 systemd-sysusers[144]: #4 0x7f356555e00e in fopen_temporary_label src/basic/fileio-label.c:63 Oct 20 09:10:49 systemd-sysusers[144]: #5 0x56197c4a1766 in make_backup src/sysusers/sysusers.c:209 Oct 20 09:10:49 systemd-sysusers[144]: #6 0x56197c4a6335 in write_files src/sysusers/sysusers.c:710 Oct 20 09:10:49 systemd-sysusers[144]: #7 0x56197c4ae571 in main src/sysusers/sysusers.c:1817 Oct 20 09:10:49 systemd-sysusers[144]: #8 0x7f3564dee730 in __libc_start_main (/lib64/libc.so.6+0x20730)
poettering
pushed a commit
that referenced
this pull request
Oct 21, 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]: #1 0x7f3565526bd0 in malloc_multiply src/basic/alloc-util.h:70 Oct 20 09:10:49 systemd-sysusers[144]: #2 0x7f356552cb55 in tempfn_xxxxxx src/basic/fileio.c:1116 Oct 20 09:10:49 systemd-sysusers[144]: #3 0x7f356552c4f0 in fopen_temporary src/basic/fileio.c:1042 Oct 20 09:10:49 systemd-sysusers[144]: #4 0x7f356555e00e in fopen_temporary_label src/basic/fileio-label.c:63 Oct 20 09:10:49 systemd-sysusers[144]: #5 0x56197c4a1766 in make_backup src/sysusers/sysusers.c:209 Oct 20 09:10:49 systemd-sysusers[144]: #6 0x56197c4a6335 in write_files src/sysusers/sysusers.c:710 Oct 20 09:10:49 systemd-sysusers[144]: #7 0x56197c4ae571 in main src/sysusers/sysusers.c:1817 Oct 20 09:10:49 systemd-sysusers[144]: #8 0x7f3564dee730 in __libc_start_main (/lib64/libc.so.6+0x20730)
evverx
referenced
this pull request
in evverx/systemd
Nov 5, 2016
Fixes:
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)
#1 0x7fb4ab5b2cc4 in malloc_multiply src/basic/alloc-util.h:70
#2 0x7fb4ab5b3194 in parse_field src/shared/logs-show.c:98
#3 0x7fb4ab5b4918 in output_short src/shared/logs-show.c:347
#4 0x7fb4ab5b7cb7 in output_journal src/shared/logs-show.c:977
#5 0x5650e29cd83d in main src/journal/journalctl.c:2581
#6 0x7fb4aabdb730 in __libc_start_main (/lib64/libc.so.6+0x20730)
SUMMARY: AddressSanitizer: 48492 byte(s) leaked in 2694 allocation(s).
Closes: systemd#4568
evverx
referenced
this pull request
in evverx/systemd
Nov 5, 2016
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)
#1 0x7fb4ab5b2cc4 in malloc_multiply src/basic/alloc-util.h:70
#2 0x7fb4ab5b3194 in parse_field src/shared/logs-show.c:98
#3 0x7fb4ab5b4918 in output_short src/shared/logs-show.c:347
#4 0x7fb4ab5b7cb7 in output_journal src/shared/logs-show.c:977
#5 0x5650e29cd83d in main src/journal/journalctl.c:2581
#6 0x7fb4aabdb730 in __libc_start_main (/lib64/libc.so.6+0x20730)
SUMMARY: AddressSanitizer: 48492 byte(s) leaked in 2694 allocation(s).
Closes: systemd#4568
evverx
referenced
this pull request
in evverx/systemd
Dec 24, 2016
"%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) #1 0x7fd9c5550bbf (/lib64/libasan.so.3+0x8ebbf) #2 0x7fd9c5552cdd in __interceptor_vsnprintf (/lib64/libasan.so.3+0x90cdd) #3 0x7fd9c5063715 in log_internalv src/basic/log.c:680 #4 0x7fd9c506390a in log_internal src/basic/log.c:697 #5 0x561d398181a2 in test_misc src/test/test-selinux.c:81 #6 0x561d398185e8 in main src/test/test-selinux.c:117 #7 0x7fd9c493a400 in __libc_start_main (/lib64/libc.so.6+0x20400) #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 ```
poettering
pushed a commit
that referenced
this pull request
Dec 25, 2016
"%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) #1 0x7fd9c5550bbf (/lib64/libasan.so.3+0x8ebbf) #2 0x7fd9c5552cdd in __interceptor_vsnprintf (/lib64/libasan.so.3+0x90cdd) #3 0x7fd9c5063715 in log_internalv src/basic/log.c:680 #4 0x7fd9c506390a in log_internal src/basic/log.c:697 #5 0x561d398181a2 in test_misc src/test/test-selinux.c:81 #6 0x561d398185e8 in main src/test/test-selinux.c:117 #7 0x7fd9c493a400 in __libc_start_main (/lib64/libc.so.6+0x20400) #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 ```
ghost
mentioned this pull request
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
using _wanted instead of calling compadd directly. this allows the user to customize
possible matches.
An example being, grouping units by type:
autoload -Uz compinit; compinit
zstyle ':completion:' menu select
zstyle ':completion:' group-name ''
zstyle ':completion:' format 'Completing %d'
zstyle -e ':completion:::systemctl-(((re|)en|dis)able|(re|)start|reload):'
tag-order 'local type; for type in service template target socket;
reply+=( systemd-units:-${type}:${type} ); reply=( "$reply systemd-units:-misc:misc" )'
zstyle ':completion::systemd-units-template' ignored-patterns '^@'
zstyle ':completion::systemd-units-target' ignored-patterns '^.target'
zstyle ':completion::systemd-units-socket' ignored-patterns '^.socket'
zstyle ':completion::systemd-units-service' ignored-patterns '^.service'
zstyle ':completion::systemd-units-misc' ignored-patterns '(@|.(service|socket|target))'