This valgrind error is raised by Ubuntu 23:10, with valgrind 1:3.21.0-0ubuntu1 and
glibc 2.38-1ubuntu6:
==141967== Source and destination overlap in memcpy_chk(0x1ffefffe98, 0x1ffefffe92, 8)
==141967== at 0x4851042: __memcpy_chk (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==141967== by 0x502A9CC: memmove (string_fortified.h:36)
==141967== by 0x502A9CC: inet_pton6 (inet_pton.c:226)
==141967== by 0x502A9CC: __inet_pton_length (inet_pton.c:56)
==141967== by 0x502A9CC: inet_pton (inet_pton.c:69)
==141967== by 0x114FA3: nmtst_inet6_from_string_p (nm-test-utils.h:1764)
==141967== by 0x114FA3: _nmtst_assert_ip6_address (nm-test-utils.h:1856)
==141967== by 0x114FA3: test_stable_privacy (test-utils.c:26)
==141967== by 0x4DEC85D: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0)
==141967== by 0x4DEC78A: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0)
==141967== by 0x4DECD2A: g_test_run_suite (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0)
==141967== by 0x4DECE07: g_test_run (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0)
==141967== by 0x4F070CF: (below main) (libc_start_call_main.h:58)
==141967==
{
<insert_a_suppression_name_here>
Memcheck:Overlap
fun:__memcpy_chk
fun:memmove
fun:inet_pton6
fun:__inet_pton_length
fun:inet_pton
fun:nmtst_inet6_from_string_p
fun:_nmtst_assert_ip6_address
fun:test_stable_privacy
obj:/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0
obj:/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0
fun:g_test_run_suite
fun:g_test_run
fun:(below main)
}
This is because memmove() can call __memcpy_chk(), which triggers the
false positive in valgrind.
It probably affects other places too, but for us it's sufficient to
restrict the valgrind suppression to calls from inet_pton(). This
suppression will probably break with LTO enabled.
See-also: https://bugs.kde.org/show_bug.cgi?id=402833https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1802
This removes libnm-glib, libnm-glib-vpn, and libnm-util for good.
The it has been replaced with libnm since NetworkManager 1.0, disabled
by default since 1.12 and no up-to-date distributions ship it for years
now.
Removing the libraries allows us to:
* Remove the horrible hacks that were in place to deal with accidental use
of both the new and old library in a single process.
* Relief the translators of maintenance burden of similar yet different
strings.
* Get rid of known bad code without chances of ever getting fixed
(libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c)
* Generally lower the footprint of the releases and our workspace
If there are some really really legacy users; they can just build
libnm-glib and friends from the NetworkManager-1.16 distribution. The
D-Bus API is stable and old libnm-glib will keep working forever.
https://github.com/NetworkManager/NetworkManager/pull/308
This removes libnm-glib, libnm-glib-vpn, and libnm-util for good.
The it has been replaced with libnm since NetworkManager 1.0, disabled
by default since 1.12 and no up-to-date distributions ship it for years
now.
Removing the libraries allows us to:
* Remove the horrible hacks that were in place to deal with accidental use
of both the new and old library in a single process.
* Relief the translators of maintenance burden of similar yet different
strings.
* Get rid of known bad code without chances of ever getting fixed
(libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c)
* Generally lower the footprint of the releases and our workspace
If there are some really really legacy users; they can just build
libnm-glib and friends from the NetworkManager-1.16 distribution. The
D-Bus API is stable and old libnm-glib will keep working forever.
https://github.com/NetworkManager/NetworkManager/pull/308
==28576== 78 (72 direct, 6 indirect) bytes in 1 blocks are definitely lost in loss record 843 of 1,311
==28576== at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==28576== by 0x6FD0A38: g_malloc (gmem.c:94)
==28576== by 0x6FE8575: g_slice_alloc (gslice.c:1025)
==28576== by 0x6FE8A08: g_slice_alloc0 (gslice.c:1051)
==28576== by 0x7010261: g_system_thread_new (gthread-posix.c:1152)
==28576== by 0x6FF283E: g_thread_new_internal (gthread.c:874)
==28576== by 0x6FF28E7: g_thread_new (gthread.c:827)
==28576== by 0x6FCC4A3: g_get_worker_context (gmain.c:5851)
==28576== by 0x681A814: g_task_thread_pool_init (gtask.c:1977)
==28576== by 0x681A814: g_task_get_type (gtask.c:592)
==28576== by 0x685CB50: ensure_required_types (gdbusprivate.c:231)
==28576== by 0x685CB50: _g_dbus_initialize (gdbusprivate.c:1927)
==28576== by 0x6850CA0: g_bus_get_sync (gdbusconnection.c:7267)
==28576== by 0x10B6AC: nmtstc_service_init (nm-test-utils-impl.c:91)
==28576== by 0x10D261: test_setup (test-secret-agent.c:249)
==28576== by 0x6FF118B: test_case_run (gtestutils.c:2160)
==28576== by 0x6FF118B: g_test_run_suite_internal (gtestutils.c:2244)
==28576== by 0x6FF139A: g_test_run_suite_internal (gtestutils.c:2256)
==28576== by 0x6FF139A: g_test_run_suite_internal (gtestutils.c:2256)
==28576== by 0x6FF1571: g_test_run_suite (gtestutils.c:2332)
==28576== by 0x6FF1590: g_test_run (gtestutils.c:1599)
==28576== by 0x10D0EE: main (test-secret-agent.c:654)
The GDBusObjectManagerClient's control proxy seems to leak some bits. Not sure
why; but certainly not our fault since it's a private object and the
manager object itself gets finalized.
Use the event socket to request object via NLM_F_DUMP.
No longer use 'priv->nlh' socket to fetch objects.
Instead fetch them via the priv->nlh_event socket that also
provides asynchronous events when objects change.
That way, the events are in sync with our explicit requests
and we can directly use the events. Previously, the events were
only used to indicate that a refetch must happen, so that every
event triggered a complete dump of all addresses/routes.
We still use 'priv->nlh' to make synchronous requests such as
adding/changing/deleting objects. That means, after we send a
request, we must make sure that the result manifested itself
at 'nlh_event' socket and the platform cache.
That's why we sometimes still must force a dump to sync changes.
That could be improved by using only one netlink socket so that
we would wait for the ACK of our request.
While not yet perfect, this already significantly reduces the number of
fetches. Additionally, before, whenever requesting a dump of addresses
or routes (which we did much more often, search for "get_kernel_object for type"
log lines), we always dumped IPv4 and IPv6 together. Now only request
the addr-family in question.
https://bugzilla.gnome.org/show_bug.cgi?id=747985https://bugzilla.redhat.com/show_bug.cgi?id=1211133
Fixes for example valgrind tests for ./libnm/tests/test-nm-client:
==25772== Conditional jump or move depends on uninitialised value(s)
==25772== at 0x40198D8: index (strchr.S:106)
==25772== by 0x400777C: expand_dynamic_string_token (dl-load.c:369)
==25772== by 0x400777C: fillin_rpath (dl-load.c:439)
==25772== by 0x4007FCF: _dl_init_paths (dl-load.c:816)
==25772== by 0x4002F38: dl_main (rtld.c:1194)
==25772== by 0x401750F: _dl_sysdep_start (dl-sysdep.c:249)
==25772== by 0x4004C20: _dl_start_final (rtld.c:306)
==25772== by 0x4004C20: _dl_start (rtld.c:412)
==25772== by 0x4000C97: ??? (in /usr/lib64/ld-2.21.so)
==25772== by 0x1: ???
==25772== by 0xFFEFFF6B2: ???
==25772== by 0xFFEFFF6EF: ???
==25772==
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:index
fun:expand_dynamic_string_token
fun:fillin_rpath
fun:_dl_init_paths
fun:dl_main
fun:_dl_sysdep_start
fun:_dl_start_final
fun:_dl_start
obj:/usr/lib64/ld-2.21.so
obj:*
obj:*
obj:*
}
Add a comment about the upstream bug that fixes
the suppressed memleak in libnl.
Also, add a different backtrace for the same bug.
It currently doesn't hit easily, because we don't
call nl_msg_parse() often. In the future we will
though.
It appears that the .isra and .part pieces can change depending on
how glib was built, so ignore those parts. Add some new suppressions
for newer glib too.
Make some suppressions more generic, because they
did not match on my F20.
The previous suppression for 'fun:gobject_init_ctor'
also had a syntax error. Fix that too.
Signed-off-by: Thomas Haller <thaller@redhat.com>
`make check` '--with-valgrind=yes' failed due to memory leaks detected
by valgrind. These leaks originate from glib structures, and should be
ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=705160
Signed-off-by: Thomas Haller <thaller@redhat.com>
This suppression didn't work on F17 for some reason, even though the
stacktrace was the same. Valgrind wanted some kind of:
obj:<path to libglib>
between the calloc and the g_malloc0 lines; but we don't actually
care much about the calloc anyway.
Create the new nm-platform framework and implement link (or interface)
management. The nm-platform serves as the point of contact between
the rest of NetworkManager and the operating system.
There are two backends for nm-platform:
* NMFakePlatform: Fake kernel backend for testing purposes
* NMLinuxPlatform: Linux kernel backend for actual use
A comprehensive testsuite is included and will be extended with new
feature additions. To enable the Linux part of the testsuite, use
--enable-tests=root configure options and run 'make check' as root.
Use --enable-code-coverage for code coverage support.
./autogen.sh --enable-tests=root --enable-code-coverage
make
make -C src/platform check-code-coverage
Link features:
* Retrieve the list of links
* Translate between indexes and names
* Discover device type
* Add/remove dummy interfaces (for testing)
Thanks to Thomas Graf for helping with libnl3 synchronization issues.
