martinpitt / umockdev

Mock hardware devices for creating unit tests and bug reporting
https://launchpad.net/umockdev
GNU Lesser General Public License v2.1
308 stars 55 forks source link

valgrind errors in rawhide #199

Closed martinpitt closed 1 year ago

martinpitt commented 2 years ago

The valgrind checks recently started to fail, for two different reasons. One can be reproduced in a DEBUG=1 test container with

G_DEBUG=fatal-warnings,fatal-criticals,gc-friendly MALLOC_CHECK_=3 LD_LIBRARY_PATH=. PATH=.:$PATH GI_TYPELIB_PATH=. TOP_SRCDIR=/source /source/src/umockdev-wrapper valgrind -q --leak-check=full --show-possibly-lost=no --errors-for-leak-kinds=definite --error-exitcode=33 --trace-children=yes --trace-children-skip=/bin*,/usr/bin/*,/usr/local/bin/* ./test-umockdev -p /umockdev-testbed/add_device_errors

which fails with

==2116== Conditional jump or move depends on uninitialised value(s)
==2116==    at 0x4974595: g_match_info_next (gregex.c:1051)
==2116==    by 0x49747AA: g_regex_match_full (gregex.c:2162)
==2116==    by 0x49748D0: g_regex_match (gregex.c:2069)
==2116==    by 0x48B5239: umockdev_testbed_record_parse_line (umockdev.vala:1479)
==2116==    by 0x48B0318: umockdev_testbed_add_dev_from_string (umockdev.vala:1303)
==2116==    by 0x48A6CF5: umockdev_testbed_add_from_string (umockdev.vala:727)
==2116==    by 0x408785: t_testbed_add_device_errors (test-umockdev.c:476)
==2116==    by 0x498AB2D: UnknownInlinedFun (gtestutils.c:2933)
==2116==    by 0x498AB2D: g_test_run_suite_internal (gtestutils.c:3021)
==2116==    by 0x498A894: g_test_run_suite_internal (gtestutils.c:3038)
==2116==    by 0x498AFFA: g_test_run_suite (gtestutils.c:3112)
==2116==    by 0x498359C: UnknownInlinedFun (gtestutils.c:2234)
==2116==    by 0x498359C: g_test_run (gtestutils.c:2221)
==2116==    by 0x41BCC9: main (test-umockdev.c:2410)
==2116== 
==2116== Conditional jump or move depends on uninitialised value(s)
==2116==    at 0x4974595: g_match_info_next (gregex.c:1051)
==2116==    by 0x49747AA: g_regex_match_full (gregex.c:2162)
==2116==    by 0x49748D0: g_regex_match (gregex.c:2069)
==2116==    by 0x48B5353: umockdev_testbed_record_parse_line (umockdev.vala:1482)
==2116==    by 0x48B0318: umockdev_testbed_add_dev_from_string (umockdev.vala:1303)
==2116==    by 0x48A6CF5: umockdev_testbed_add_from_string (umockdev.vala:727)
==2116==    by 0x408785: t_testbed_add_device_errors (test-umockdev.c:476)
==2116==    by 0x498AB2D: UnknownInlinedFun (gtestutils.c:2933)
==2116==    by 0x498AB2D: g_test_run_suite_internal (gtestutils.c:3021)
==2116==    by 0x498A894: g_test_run_suite_internal (gtestutils.c:3038)
==2116==    by 0x498AFFA: g_test_run_suite (gtestutils.c:3112)
==2116==    by 0x498359C: UnknownInlinedFun (gtestutils.c:2234)
==2116==    by 0x498359C: g_test_run (gtestutils.c:2221)
==2116==    by 0x41BCC9: main (test-umockdev.c:2410)
==2116== 
# DEBUG: umockdev.vala:1363: creating device /devices/target (subsystem foo)
==2116== Conditional jump or move depends on uninitialised value(s)
==2116==    at 0x4974595: g_match_info_next (gregex.c:1051)
==2116==    by 0x49747AA: g_regex_match_full (gregex.c:2162)
==2116==    by 0x49760CF: g_regex_replace_eval (gregex.c:3354)
==2116==    by 0x497651A: g_regex_replace_literal (gregex.c:3255)
==2116==    by 0x48A2848: string_replace (glib-2.0.vapi:1548)
==2116==    by 0x48A43B1: umockdev_testbed_add_devicev_no_uevent (umockdev.vala:486)
==2116==    by 0x48B2FB2: umockdev_testbed_add_dev_from_string (umockdev.vala:1364)
==2116==    by 0x48A6CF5: umockdev_testbed_add_from_string (umockdev.vala:727)
==2116==    by 0x408785: t_testbed_add_device_errors (test-umockdev.c:476)
==2116==    by 0x498AB2D: UnknownInlinedFun (gtestutils.c:2933)
==2116==    by 0x498AB2D: g_test_run_suite_internal (gtestutils.c:3021)
==2116==    by 0x498A894: g_test_run_suite_internal (gtestutils.c:3038)
==2116==    by 0x498AFFA: g_test_run_suite (gtestutils.c:3112)

Most tests fail due to this. This smells like a bug in glib, as it happens through other code paths as well, e.g.

==3350== Conditional jump or move depends on uninitialised value(s)
==3350==    at 0x4974595: g_match_info_next (gregex.c:1051)
==3350==    by 0x49747AA: g_regex_match_full (gregex.c:2162)
==3350==    by 0x49748D0: g_regex_match (gregex.c:2069)
==3350==    by 0x48ABE3C: umockdev_testbed_load_evemu_events (umockdev.vala:1086)
benzea commented 2 years ago

Wasn't GRegex recently ported to a newer version of the PCRE library?

i.e. https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2529

martinpitt commented 1 year ago

This is an actual issue, tracked in https://gitlab.gnome.org/GNOME/glib/-/issues/2741 . It was fixed 5 days ago, and just needs a new release now. I'll give this a few more days then, as it's awkward to ignore.

martinpitt commented 1 year ago

This should be fixed in glib 2.74.0, which is in rawhide, Debian unstable, and Ubuntu devel series now. And indeed the latest run is all green again! :green_heart: