[91/180] Compiling C object libsystemd.a.p/src_libsystemd_sd-event_sd-event.c.o
In file included from ../src/basic/macro.h:12,
from ../src/basic/alloc-util.h:9,
from ../src/libsystemd/sd-event/sd-event.c:11:
../src/libsystemd/sd-event/sd-event.c: In function ‘sd_event_wait’:
../src/fundamental/macro-fundamental.h:86:63: warning: ‘child_min_priority’ may be used uninitialized in this function [-Wmaybe-uninitialized]
86 | UNIQ_T(A, aq) < UNIQ_T(B, bq) ? UNIQ_T(A, aq) : UNIQ_T(B, bq); \
| ^
../src/libsystemd/sd-event/sd-event.c:3983:45: note: ‘child_min_priority’ was declared here
3983 | int64_t epoll_min_priority, child_min_priority;
| ^~~~~~~~~~~~~~~~~~
Alternative to #19159.
It was one giant all of text in pseudo-random order. Let's split it into
paragraphs talk about one subject each.
And unfortunately, the description of what happens when the error is not
set was not correct. In general, various functions treat 0/NULL as
not-an-error, and return 0.
I was hoping it would help with the following gcc warning:
[35/657] Compiling C object src/shared/libsystemd-shared-248.a.p/bus-message-util.c.o
../src/shared/bus-message-util.c: In function ‘bus_message_read_dns_servers’:
../src/shared/bus-message-util.c:165:21: warning: ‘family’ may be used uninitialized in this function [-Wmaybe-uninitialized]
165 | r = in_addr_full_new(family, &a, port, 0, server_name, dns + n);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/shared/bus-message-util.c:165:21: warning: ‘port’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../src/shared/bus-message-util.c:165:21: warning: ‘server_name’ may be used uninitialized in this function [-Wmaybe-uninitialized]
It actually doesn't, but the compiler has a point here: the code is specified
in sd_bus_error_map[], and it has no way of knowning that we want it to be a
positive value.
I think this should be an assert, because if this assumption fails, a
programming error has occured, something that'd want to catch.
Check the return code from gcrypt's functions. In some
cases just log, as it shoulnd't really happen.
Fixes various Coverity issues:
CID #1444702
CID #1444704
CID #1444706
CID #1444711
CID #1444712
CID #1444713
The advantage of stream compression is keeping a low memory profile,
but the lz4 stream compressor usage mmaps the whole file in memory.
Change it to read bits by bits, like the other stream compression
helpers.
LLD 13 and GNU ld 2.37 support -z start-stop-gc which allows garbage
collection of C identifier name sections despite the __start_/__stop_
references. Simply set the retain attribute so that GCC 11 (if
configure-time binutils is 2.36 or newer)/Clang 13 will set the
SHF_GNU_RETAIN section attribute to prevent garbage collection.
Without the patch, there are linker errors like the following with -z
start-stop-gc.
```
ld: error: undefined symbol: __start_SYSTEMD_BUS_ERROR_MAP
>>> referenced by bus-error.c:93 (../src/libsystemd/sd-bus/bus-error.c:93)
>>> sd-bus_bus-error.c.o:(bus_error_name_to_errno) in archive src/libsystemd/libsystemd_static.a
```
Coverity was complaining that we don't check the return value, which we stopped
doing in 772e0a76f3.
But it seems that we don't want those calls at all. The test was originally
added with the call in a6ee01caf3, but I don't
see why we should override this. If the user wants to execute the test with
mempool disabled, we shouldn't ignore that.
Coverity CID#1444464, CID#1444466.
This reverts the gist of commit 798445ab84.
Unfortunately the new syscall causes test-event to hang. 32 bit architectures
seem affected: i686 and arm32 in fedora koji. 32 bit build of test-event hangs
reliably under valgrind:
$ PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig meson build-32 -Dc_args=-m32 -Dc_link_args=-m32 -Dcpp_args=-m32 -Dcpp_link_args=-m32 && ninja -C build-32 test-event && valgrind build/test-event
If I set epoll_pwait2_absent=true, so the new function is never called, then
the issue does not reproduce. It seems to be strictly tied to the syscall.
On amd64, the syscall is not used, at least with the kernel that Fedora
provides. The kernel patch 58169a52ebc9a733aeb5bea857bc5daa71a301bb says:
For timespec, only support this new interface on 2038 aware platforms
that define __kernel_timespec_t. So no CONFIG_COMPAT_32BIT_TIME.
And Fedora sets CONFIG_COMPAT_32BIT_TIME=y. I expect most other distros will too.
On amd64: epoll_wait_usec: epoll_pwait2: ret=-1 / errno=38
On i686 (same kernel): epoll_wait_usec: epoll_pwait2: ret=2 / errno=0
Is this some kind of emulation? Anyway, it seems that this is what is going wrong.
So let's disable the syscall until it becomes more widely available and the
kinks have been ironed out.
Fixes test-event issue in #19052.
Wherever we read virtual files we better should use
read_full_virtual_file(), to make sure we get a consistent response
given how weird the kernel's handling with partial read on such file
systems is.
Previously, when a process outputs something and exit just after
epoll_wait() but before process_child(), then the IO event is ignored
even if the IO event has higher priority. See #18190.
This can be solved by checking epoll event again after process_child().
However, there exists a possibility that another process outputs and
exits just after process_child() but before the second epoll_wait().
When the IO event has lower priority than the child event, still IO
event is processed.
So, this makes new epoll events and child events are checked in a loop
until no new event is detected. To prevent an infinite loop, the number
of maximum trial is set to 10.
Fixes#18190.
Previously, when a process outputs something and exit just after
epoll_wait() but before process_child(), then the IO event is ignored
even if the IO event has higher priority. See #18190.
This can be solved by checking epoll event again after process_child().
However, there exists a possibility that another process outputs and
exits just after process_child() but before the second epoll_wait().
When the IO event has lower priority than the child event, still IO
event is processed.
So, this makes new epoll events and child events are checked in a loop
until no new event is detected. To prevent an infinite loop, the number
of maximum trial is set to 10.
Fixes#18190.
We use 'unsigned' as the type, but netlink(7) says the type is 'int'.
It doesn't really matter, since they are both the same size. Let's use
our helper to shorten the code a bit.
Also use structued initialization in one more place, use '\0' for NUL bytes,
and move variable to the right block (the code was OK, but it is strange to
have 'char *value' defined in a different scope then 'size_t value_allocated').
This fuzzer is based on test-bus-match. Even the initial corpus is
derived entirely from it.
https://bugzilla.redhat.com/show_bug.cgi?id=1935084 shows an crash
in bus_match_parse(). I checked the coverage stats on oss-fuzz, and
sadly existing fuzzing did not cover this code at all.
I'm getting the following error under valgrind:
==305970== Invalid free() / delete / delete[] / realloc()
==305970== at 0x483E9F1: free (vg_replace_malloc.c:538)
==305970== by 0x4012CD: mfree (alloc-util.h:48)
==305970== by 0x4012EF: freep (alloc-util.h:83)
==305970== by 0x4017F4: LLVMFuzzerTestOneInput (fuzz-bus-match.c:58)
==305970== by 0x401A58: main (fuzz-main.c:39)
==305970== Address 0x59972f0 is 0 bytes inside a block of size 8,192 free'd
==305970== at 0x483FCE4: realloc (vg_replace_malloc.c:834)
==305970== by 0x4C986F7: _IO_mem_finish (in /usr/lib64/libc-2.33.so)
==305970== by 0x4C8F5E0: fclose@@GLIBC_2.2.5 (in /usr/lib64/libc-2.33.so)
==305970== by 0x49D2CDB: fclose_nointr (fd-util.c:108)
==305970== by 0x49D2D3D: safe_fclose (fd-util.c:124)
==305970== by 0x4A4BCCC: fclosep (fd-util.h:41)
==305970== by 0x4A4E00F: bus_match_to_string (bus-match.c:859)
==305970== by 0x4016C2: LLVMFuzzerTestOneInput (fuzz-bus-match.c:58)
==305970== by 0x401A58: main (fuzz-main.c:39)
==305970== Block was alloc'd at
==305970== at 0x483FAE5: calloc (vg_replace_malloc.c:760)
==305970== by 0x4C98787: open_memstream (in /usr/lib64/libc-2.33.so)
==305970== by 0x49D56D6: open_memstream_unlocked (fileio.c:97)
==305970== by 0x4A4DEC5: bus_match_to_string (bus-match.c:859)
==305970== by 0x4016C2: LLVMFuzzerTestOneInput (fuzz-bus-match.c:58)
==305970== by 0x401A58: main (fuzz-main.c:39)
==305970==
So the fclose() which is called from _cleanup_fclose_ clearly reallocates the
buffer (maybe to save memory?). open_memstream(3) says:
The locations referred to by these pointers are updated each time the
stream is flushed (fflush(3)) and when the stream is closed (fclose(3)).
This seems to mean that we should close the stream first before grabbing the
buffer pointer.
