unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Ekaitz Zarraga <ekaitz@elenq.tech>
To: "greenfork.lists@yandex.com" <greenfork.lists@yandex.com>
Cc: "help-guix@gnu.org" <help-guix@gnu.org>
Subject: Re: How to debug hanging "check" phase when building Kakoune
Date: Sun, 18 Apr 2021 10:42:09 +0000	[thread overview]
Message-ID: <9-XX1BFfXeeBAnqcuj6YIDH3DiJxFUCMZ0aHcWRWl97LVBS7DXpElt9DZkmQusNFEhtcpFYcXNrLGi7ESUCHLviIARipPJRSUYh8qlq0H9M=@elenq.tech> (raw)
In-Reply-To: <87sg3ocdmb.fsf@yandex.com>

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


  reply	other threads:[~2021-04-18 10:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-18  6:26 How to debug hanging "check" phase when building Kakoune Dmitry Matveyev
2021-04-18 10:42 ` Ekaitz Zarraga [this message]
2021-04-18 14:12   ` Dmitry Matveyev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='9-XX1BFfXeeBAnqcuj6YIDH3DiJxFUCMZ0aHcWRWl97LVBS7DXpElt9DZkmQusNFEhtcpFYcXNrLGi7ESUCHLviIARipPJRSUYh8qlq0H9M=@elenq.tech' \
    --to=ekaitz@elenq.tech \
    --cc=greenfork.lists@yandex.com \
    --cc=help-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).