After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 705160 - make check fails
make check fails
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Pavel Simerda
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-07-30 18:00 UTC by Kjartan Maraas
Modified: 2013-12-11 14:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
valgrind log from test-address-fake test (68.67 KB, text/plain)
2013-08-17 21:53 UTC, Kjartan Maraas
  Details
valgrind log from test-cleanup-fake test (68.67 KB, text/plain)
2013-08-17 21:54 UTC, Kjartan Maraas
  Details
test-link-fake valgrind log (68.67 KB, text/plain)
2013-08-17 21:54 UTC, Kjartan Maraas
  Details
test-route-fake valgrind log (68.67 KB, text/plain)
2013-08-17 21:54 UTC, Kjartan Maraas
  Details
update valgrind.suppressions (1017 bytes, patch)
2013-10-02 10:06 UTC, Thomas Haller
none Details | Review
[PATCH] valgrind.suppressions (702 bytes, patch)
2013-11-15 18:19 UTC, Thomas Haller
none Details | Review

Description Kjartan Maraas 2013-07-30 18:00:57 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
Comment 1 Pavel Simerda 2013-07-30 18:10:17 UTC
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.
Comment 2 Dan Williams 2013-07-30 18:13:34 UTC
Hmm, can you add --disable-valgrind to the configure flags?
Comment 3 Kjartan Maraas 2013-07-31 11:13:14 UTC
Adding --with-valgrind=no "fixed" it for me.
Comment 4 Pavel Simerda 2013-07-31 11:33:05 UTC
(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.
Comment 5 Pavel Simerda 2013-07-31 11:34:06 UTC
(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.
Comment 6 Pavel Simerda 2013-08-13 21:38:48 UTC
Setting NEEDINFO for the valgrind logs.
Comment 7 Kjartan Maraas 2013-08-17 21:53:27 UTC
Created attachment 252073 [details]
valgrind log from test-address-fake test
Comment 8 Kjartan Maraas 2013-08-17 21:54:00 UTC
Created attachment 252074 [details]
valgrind log from test-cleanup-fake test
Comment 9 Kjartan Maraas 2013-08-17 21:54:22 UTC
Created attachment 252075 [details]
test-link-fake valgrind log
Comment 10 Kjartan Maraas 2013-08-17 21:54:58 UTC
Created attachment 252076 [details]
test-route-fake valgrind log
Comment 11 Pavel Simerda 2013-10-01 18:56:07 UTC
Thanks for the feedback and sorry for not answering earlier.
Comment 12 Thomas Haller 2013-10-02 10:06:08 UTC
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.
Comment 13 Pavel Simerda 2013-10-02 10:15:29 UTC
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.
Comment 14 Dan Williams 2013-11-15 17:56:44 UTC
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.
Comment 15 Thomas Haller 2013-11-15 18:17:31 UTC
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
    ...
}
Comment 16 Thomas Haller 2013-11-15 18:19:47 UTC
Created attachment 259935 [details] [review]
[PATCH] valgrind.suppressions

A patch as suggested in comment #15
Comment 17 Dan Williams 2013-12-05 23:16:48 UTC
(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.
Comment 18 Jiri Klimes 2013-12-11 12:25:25 UTC
Looks fine for me.