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 739127 - [review] lr/rpm-make-check: Several test failures
[review] lr/rpm-make-check: Several test failures
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-10-24 13:55 UTC by Lubomir Rintel
Modified: 2014-11-07 15:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Comment 1 Thomas Haller 2014-10-24 14:34:39 UTC
>> core: Fall back to CLOCK_MONOTONIC if CLOCK_BOOTTIME unsupported

How about the fixup I pushed on top of your branch?

It saves the call to "clock_gettime (CLOCK_BOOTTIME, tp);" that is going to fail every time.

but more importantly, it decides once which clock to use and sticks to that.




The rest looks good (including "contrib/rpm: Run make check")
Comment 2 Dan Winship 2014-10-24 14:48:55 UTC
> tests: Don't run session-long dbus daemons for tests

Oh, huh. I had thought "dbus-launch --exit-with-session CMD" worked the same way as, eg, "ssh-agent CMD" or "gpg-agent --daemon CMD" (where it exits when CMD exits)...

>+    eval `dbus-launch`
>+    export DBUS_SESSION_BUS_ADDRESS

if you do

  eval `dbus-launch --sh-syntax`

it will include the export command for you.


> core: Fall back to CLOCK_MONOTONIC if CLOCK_BOOTTIME unsupported

I like Thomas's fix to only end up calling with the wrong value once.

(Also, maybe there should be a comment in the code pointing out that it's only needed for mock builds on RHEL-6, so we know when it's safe to delete it.)


> libnm: Ignore NoReply errors when NM has vanished from the bus

Someone else posted a patch for this to some other branch too, but I can't remember where. I think the other one was more complicated than yours, but yours looks like it should work fine.
Comment 3 Dan Winship 2014-10-24 14:56:24 UTC
ah, the other client-nm-running fix was in dcbw/libnm-fixes, bug 738588
Comment 6 Lubomir Rintel 2014-10-29 11:23:25 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=lr/rpm-make-check&id=785144510710a32ab8b3779b0d81d201d3a69941
> 
> I think this should be different. Pushed a fixup.

Applied.

Note that I've last seen the test fail the last Thursday and could not make it fail afterwards therefore I'm having trouble verifying the fix. Maybe some other change fixed it?
Comment 7 Dan Winship 2014-10-29 13:11:08 UTC
What bug does the "Don't clean up the connections if they hadn't been set yet." change fix?

In particular, the reason it currently unsets priv->all_connections first, and then works from a local copy of it, is to guarantee that nothing that any CONNECTION_REMOVED signal handler does can cause priv->all_connections to be modified while we're iterating it. (In this case, I'm not sure there's anything a signal handler could do that would mess things up anyway, but it's good defensive coding anyway...)
Comment 8 Lubomir Rintel 2014-10-29 14:04:34 UTC
(In reply to comment #7)
> What bug does the "Don't clean up the connections if they hadn't been set yet."
> change fix?

I've seen a connections == NULL here when running the nm-client-test repeatedly (unfortunately I've lost the screen capture):

g_ptr_array_unref (connections);

I've concluded that nm_running_changed() may be triggered very early if the daemon terminates before we've gotten the connection list.
Comment 9 Dan Winship 2014-10-29 16:22:03 UTC
(In reply to comment #8)
> I've seen a connections == NULL here when running the nm-client-test repeatedly
...
> I've concluded that nm_running_changed() may be triggered very early if the
> daemon terminates before we've gotten the connection list.

Hm... priv->all_connections is never NULL until after dispose(). So the only way connections could be NULL is if nm_running_changed() ran after dispose(), and your patch already fixes that case separately anyway, so I don't think the nm_running_changed() part of the patch is needed.
Comment 10 Thomas Haller 2014-10-29 16:42:12 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > I've seen a connections == NULL here when running the nm-client-test repeatedly
> ...
> > I've concluded that nm_running_changed() may be triggered very early if the
> > daemon terminates before we've gotten the connection list.
> 
> Hm... priv->all_connections is never NULL until after dispose(). So the only
> way connections could be NULL is if nm_running_changed() ran after dispose(),
> and your patch already fixes that case separately anyway, so I don't think the
> nm_running_changed() part of the patch is needed.


The call to cleanup_connection() seems still needed to me.

I agree, with your point on defensive. But then the best way seem to be:

         /* Clear connections */
         while (priv->all_connections->len) {
              guint idx = priv->all_connections->len - 1;
              NMRemoteConnection *connection = priv->all_connections->pdata[idx];

              g_ptr_array_remove_index (priv->all_connections, idx);
              cleanup_connection (self, connection);
              g_signal_emit (self, signals[CONNECTION_REMOVED], 0, connection);
         }
Comment 11 Dan Winship 2014-10-29 17:37:04 UTC
(In reply to comment #10)
> The call to cleanup_connection() seems still needed to me.

Though admittedly non-obvious, cleanup_connection() already gets called, from within connection_removed() when we emit the connection-removed signal
Comment 12 Thomas Haller 2014-10-29 18:15:44 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > The call to cleanup_connection() seems still needed to me.
> 
> Though admittedly non-obvious, cleanup_connection() already gets called, from
> within connection_removed() when we emit the connection-removed signal


ah indeed. That might be worth a comment.
Comment 13 Dan Williams 2014-10-31 14:08:11 UTC
It seems like this branch already got merged?  Can the bug be closed now?