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

[Ludovic Courtès]

l...@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’.

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
, which
uses .)

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’.