How to debug hanging "check" phase when building Kakoune

How to debug hanging "check" phase when building Kakoune

[Dmitry Matveyev]

Hi,

I use guix on Arch Linux, version
050be36cbf3a42199f64f2e44c59f1cb1b3afab5.

When I run

     guix build --check kakoune

everything builds correctly.

Now I change original `source` definition to fetch not from url but from
git repository. Original source and version:

    (version "2020.09.01")
    (source
     (origin
       (method url-fetch)
       (uri (string-append "https://github.com/mawww/kakoune/"
                           "releases/download/v" version "/"
                           "kakoune-" version ".tar.bz2"))
       (sha256
        (base32 "0x81rxy7bqnhd9374g5ypy4w4nxmm0vnqw6b52bf62jxdg2qj6l6"))))

And my modified kakoune package:

    (define-module (mykak)
      #:use-module (guix packages)
      #:use-module (guix git-download)
      #:use-module (gnu packages text-editors))
    
    (package
      (inherit kakoune)
      (version "2020.09.01")
      (source
       (origin
         (method git-fetch)
         (uri (git-reference
               (url "https://github.com/mawww/kakoune.git")
               (commit (string-append "v" version))))
         (file-name (git-file-name "mykak" version))
         (sha256
          (base32
           "091qzk0qs7hql0q51hix99srgma35mhdnjfd5ncfba1bmc1h8x5i")))))

Now when I run to build this package, assuming it is named
`kakoune.scm`:

    guix build --check -f kakoune.scm

it freezes with this output:

    phase `build' succeeded after 29.7 seconds
    starting phase `check'
    ln -sf kak.opt kak
    cd ../test && ./run
      kak-tests.R6Lc8cJk
        compose

And the problem as I figured out with printf debugging is on this line:

https://github.com/mawww/kakoune/blob/v2020.09.01/test/run#L71

Same result is when I manually download tarball from github, unpack and
use it to build the package:

    (define-module (mykak)
      #:use-module (guix packages)
      #:use-module (guix download)
      #:use-module (guix gexp)
      #:use-module (gnu packages text-editors))
    
    (package
      (inherit kakoune)
      (version "2020.09.01")
      (source
       (local-file "/tmp/kakoune-2020.09.01" #:recursive? #t)))

I have assumption that this is somehow connected with read-write
permissions because when I keep failed builds and later try to delete
them, it asks whether I really want to delete some read-only files.

I have no idea how exactly that `test/run` script works with all the
pipes and output redirection. And I have no idea how to check why this
build phase hangs. Any tips would be really helpful.


Regards,

Dmitry.

Re: How to debug hanging "check" phase when building Kakoune

[Ekaitz Zarraga]

Hey!

Pretty cool question, let's see if my Bash skills are not lost like tears
in the rain.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, April 18, 2021 8:26 AM, Dmitry Matveyev <greenfork.lists@yandex.com> wrote:

>
> I have assumption that this is somehow connected with read-write
> permissions because when I keep failed builds and later try to delete
> them, it asks whether I really want to delete some read-only files.
>
> I have no idea how exactly that `test/run` script works with all the
> pipes and output redirection. And I have no idea how to check why this
> build phase hangs. Any tips would be really helpful.


I agree, it looks like it's related with that.

That `cat` you marked there is reading from the file descriptor 4 and
discarding its output. That's not a reasonable thing to do in general,
*unless* you are reading from a file that is being written to as a
pipe (this case is a named pipe, done with `mkfifo`).

The `exec 4<ui-out 3>ui-in` is opening those files and binding them
to the file descriptors. So any time you see reading from the fd 4 they
are reading from ui-out

Pipes are special files that can be used for inter-process communication
in this case I think this cat is reading from the pipe until it's
empty, in order to consume the data that is being sent by a process.

My guess is that the ui-out and ui-in fifos don't have write permission
so the process is not able to run, and it hangs in the write, or it's
the `cat` who dies in the reading from an empty fifo. It's going to
wait until an EOF comes, and that's not happening, because none can
write the EOF there.

Does this make any sense?

HTH,
Ekaitz

Re: How to debug hanging "check" phase when building Kakoune

[Dmitry Matveyev]

Hi, Ekaitz!

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

> Does this make any sense?

Thank you a lot, this totally makes sense. I will try to find out why
this is happening further.


Regards,

Dmitry.