GNOME Bugzilla – Bug 705160
make check fails
Last modified: 2013-12-11 14:33:51 UTC
Make check is failing on these: Don't forget to check the valgrind log at '/home/kmaraas/src/gnome/NetworkManager/src/platform/tests/valgrind-test-link-fake.log'. FAIL: test-link-fake /address/internal/ip4: OK /address/internal/ip6: OK Don't forget to check the valgrind log at '/home/kmaraas/src/gnome/NetworkManager/src/platform/tests/valgrind-test-address-fake.log'. FAIL: test-address-fake /route/ip4: OK /route/ip6: OK Don't forget to check the valgrind log at '/home/kmaraas/src/gnome/NetworkManager/src/platform/tests/valgrind-test-route-fake.log'. FAIL: test-route-fake /internal: OK Don't forget to check the valgrind log at '/home/kmaraas/src/gnome/NetworkManager/src/platform/tests/valgrind-test-cleanup-fake.log'. FAIL: test-cleanup-fake
My output is: make[4]: Entering directory `/root/NetworkManager/src/platform/tests' /link/bogus: OK /link/loopback: OK /link/internal: OK /link/software/bridge: OK /link/software/bond: OK /link/software/team: OK /link/software/vlan: OK PASS: test-link-fake /address/internal/ip4: OK /address/internal/ip6: OK PASS: test-address-fake /route/ip4: OK /route/ip6: OK PASS: test-route-fake /internal: OK PASS: test-cleanup-fake /link/bogus: OK /link/loopback: OK /link/internal: OK /link/software/bridge: OK /link/software/bond: OK /link/software/team: OK /link/software/vlan: OK /link/external: OK PASS: test-link-linux /address/internal/ip4: OK /address/internal/ip6: OK /address/external/ip4: OK /address/external/ip6: OK PASS: test-address-linux /route/ip4: OK /route/ip6: OK PASS: test-route-linux /internal: OK PASS: test-cleanup-linux ================== All 8 tests passed ================== But you also have the 'fake' variants failed, which disproves a libnl-related problem. I tested commit cfa4117ebb6a928ef3332f5c606bbfbf4b7159d7. If you receive all 'OK' without any errors but it still fails that means it's a valgrind-reported failure. I will need the valgrind log files.
Hmm, can you add --disable-valgrind to the configure flags?
Adding --with-valgrind=no "fixed" it for me.
(In reply to comment #2) > Hmm, can you add --disable-valgrind to the configure flags? When it's not valgrind, you get specific assertions/errors in the output. (In reply to comment #3) > Adding --with-valgrind=no "fixed" it for me. It confirms that we need the valgrind logs mentioned in your output. It might be handy to know versions of critical components like kernel, libnl3 and of course valgrind. Optionally you can specify your distribution, etc.
(In reply to comment #4) > It confirms that we need the valgrind logs mentioned in your output. It might > be handy to know versions of critical components like kernel, libnl3 and of > course valgrind. Optionally you can specify your distribution, etc. Ah sorry, you're only testing the 'fake' tests, therefore *only* valgrind applies from the list above.
Setting NEEDINFO for the valgrind logs.
Created attachment 252073 [details] valgrind log from test-address-fake test
Created attachment 252074 [details] valgrind log from test-cleanup-fake test
Created attachment 252075 [details] test-link-fake valgrind log
Created attachment 252076 [details] test-route-fake valgrind log
Thanks for the feedback and sorry for not answering earlier.
Created attachment 256245 [details] [review] update valgrind.suppressions With this, `make check` does no longer report any errors for me. I *think* that it does not hide any real, relevant leaks.
Review of attachment 256245 [details] [review]: The second rule would catch virtually all memory allocations in _dl_init. I'm curious whether we shouldn't: a) Make the rule more specific and catch some specific function. b) Make the rule less specific and catch *all* _dl_init allocations. The first rule (and maybe other rules) wouldn't be needed then.
What if we just hide anything that comes after gobject_init_ctor()? That function only gets called once at module load, and it's one-time initialization stuff that isn't our problem because it's gobject, and it's initialization code.
That does not work for me, my errors look more like this: { <insert_a_suppression_name_here> Memcheck:Leak fun:calloc fun:g_malloc0 obj:/usr/lib64/libgobject-2.0.so.0.3600.3 fun:g_type_register_fundamental obj:/usr/lib64/libgobject-2.0.so.0.3600.3 obj:/usr/lib64/libgobject-2.0.so.0.3600.3 fun:_dl_init obj:/usr/lib64/ld-2.17.so } Maybe this is because I have libgobject from system (without debug information?). The following suppressions work for me, so lets add them: { _dl_init_g_type_register_fundamental Memcheck:Leak ... fun:g_type_register_fundamental ... obj:/*/libgobject* fun:_dl_init obj:/*/ld-*.so } { _dl_init_g_malloc0 Memcheck:Leak fun:calloc fun:g_malloc0 ... obj:/*/libgobject* fun:_dl_init obj:/*/ld-*.so } and also add: { ... fun:gobject_init_ctor ... }
Created attachment 259935 [details] [review] [PATCH] valgrind.suppressions A patch as suggested in comment #15
(In reply to comment #16) > Created an attachment (id=259935) [details] [review] > [PATCH] valgrind.suppressions > > A patch as suggested in comment #15 Works for me.
Looks fine for me.
Patch pushed to master: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=2540966492340ad87cd5a894d544580b8e20c558