GLib’s ‘network-address’ test failure

GLib’s ‘network-address’ test failure

[Ludovic Courtès]

GLib’s ‘network-address’ test is currently failing on Hydra,
specifically the assertion in this function (as reported by Mark and
Andreas):

--8<---------------cut here---------------start------------->8---
static void
find_ifname_and_index (void)
{
  if (SCOPE_ID_TEST_INDEX != 0)
    return;

#ifdef HAVE_IF_INDEXTONAME
  for (SCOPE_ID_TEST_INDEX = 1; SCOPE_ID_TEST_INDEX < 255; SCOPE_ID_TEST_INDEX++) {
    if (if_indextoname (SCOPE_ID_TEST_INDEX, SCOPE_ID_TEST_IFNAME))
      break;
  }
  g_assert_cmpstr (SCOPE_ID_TEST_IFNAME, !=, "");
#endif
}
--8<---------------cut here---------------end--------------->8---

To see what ‘if_indextoname’ returns in our chroot, I tried this:

--8<---------------cut here---------------start------------->8---
(use-modules (guix store) (guix derivations) (guix monads) (guix utils)
             (gnu packages guile))

(define builder '(begin
                   (use-modules (system foreign)
                                (rnrs bytevectors)
                                (srfi srfi-1))

                   (let ()
                     (define index->name
                       (let* ((ptr (dynamic-func "if_indextoname" (dynamic-link)))
                              (proc (pointer->procedure '* ptr
                                                        (list unsigned-int '*))))
                         (lambda (index)
                           (let* ((bv  (make-bytevector 256))
                                  (ret (proc index
                                             (bytevector->pointer bv))))
                             (if (null-pointer? ret)
                                 #f
                                 (pointer->string ret))))))
                     (call-with-output-file (assoc-ref %outputs "out")
                       (lambda (port)
                         (write (zip (map index->name (iota 10))
                                     (iota 10))
                                port))))))

(let* ((mdrv (derivation-expression "iface" (%current-system) builder '()))
       (s    (open-connection))
       (drv  (run-with-store s mdrv)))
  (pk drv)
  (build-derivations s (list drv)))
--8<---------------cut here---------------end--------------->8---

That returns a series of #f (whereas outside of the chroot BUILDER
returns '("lo" "eth0" "wlan0").)

This is a consequence of using CLONE_NEWNET, AIUI (see
<http://lxr.free-electrons.com/source/net/core/dev_ioctl.c#L20>, which
uses <http://lxr.free-electrons.com/source/net/core/dev.c#L812>.)

Now I don’t understand why the test passed, as least sometimes (it
certainly did on my machine.)  Ideas welcome.

Anyway, I’ll come up with a simple patch to fix that.

Thanks,
Ludo’.

Re: GLib’s ‘network-address’ test failure

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> To see what ‘if_indextoname’ returns in our chroot, I tried this:
>
> (use-modules (guix store) (guix derivations) (guix monads) (guix utils)
>              (gnu packages guile))
>
> (define builder '(begin
>                    (use-modules (system foreign)
>                                 (rnrs bytevectors)
>                                 (srfi srfi-1))
>
>                    (let ()
>                      (define index->name
>                        (let* ((ptr (dynamic-func "if_indextoname" (dynamic-link)))
>                               (proc (pointer->procedure '* ptr
>                                                         (list unsigned-int '*))))
>                          (lambda (index)
>                            (let* ((bv  (make-bytevector 256))
>                                   (ret (proc index
>                                              (bytevector->pointer bv))))
>                              (if (null-pointer? ret)
>                                  #f
>                                  (pointer->string ret))))))
>                      (call-with-output-file (assoc-ref %outputs "out")
>                        (lambda (port)
>                          (write (zip (map index->name (iota 10))
>                                      (iota 10))
>                                 port))))))
>
> (let* ((mdrv (derivation-expression "iface" (%current-system) builder '()))
>        (s    (open-connection))
>        (drv  (run-with-store s mdrv)))
>   (pk drv)
>   (build-derivations s (list drv)))
>
> That returns a series of #f (whereas outside of the chroot BUILDER
> returns '("lo" "eth0" "wlan0").)

On IRC Mark noted that nix/libstore/build.cc sets up ‘lo’ in the chroot,
so that one should appear.

It turns out that it does indeed appear, but its index is incremented by
one each time guix-daemon starts a child process.  Thus, when doing a
whole series of builds in a row, or if the machine has been up long
enough, you may end up with an index greater than 255, leading to the
assertion failure in ‘find_ifname_and_index’ (this explains why Hydra
was hitting it and not my laptop, for instance.)

If the explanation is correct, 93a3d8f fixes the problem.

Thanks,
Ludo’.