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

[Ludovic Courtès]

address@hidden (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’.