Emacs 29.3; suspicious error message from compile command in Emacs 29.3

The following error message appears in the terminal from which emacs was started every time I use the 'compile' command:

> emacs: writing to child signal FD: Invalid argument

The compilation itself (via make) works perfectly fine. Only this new message is a bit annoying. And so cryptic, isn't it? It did not appear up until the latest update.

This error message (or whatever it is) appears also, when I start emacs from a non-X tty (Ctrl + Alt + F2) and with '-Q' option. To be precise, it appears when I use 'M-x compile' and for longer compilation processes it appears at the end of the compilation, not at the beginning.

I asked for help with that at the GNU bugtracker and got the following answer:

> On 4/22/24 21:40, Eli Zaretskii wrote:
>> When a sub-process exits, Emacs writes to file descriptor which it
>> monitors with pselect. This is so we don't miss SIGCHLD for some
>> reason. Why in your case this write errors out with EINVAL, I don't
>> know. Perhaps Paul (CC'ed) could have some ideas.
>>
>> If this could happen for benign reasons, maybe we should silently
>> ignore these errors.

And then:

Please do report to them (slackware), it cannot possibly do any harm. When you
do, please ask them to tell us here whether this could be caused by
some downstream change they made in Emacs, or by some of the libraries
you have installed.

My question here: Gets anyone the same message when using the M-x compile command in Emacs 29.3 on slackware? And if so, where is the correct place for filing a bug report?

Which emacs is it?

• slackware64-15.0: patches/packages/emacs-29.3-x86_64-1_slack15.0.txz
• slackware64-current: e/emacs-29.3-x86_64-1.txz
• slackware64-current: extra/emacs-regular-build/emacs-29.3-x86_64-1_regular.txz

Originally Posted by 3Tom The following error message appears in the terminal from which emacs was started every time I use the 'compile' command: > emacs: writing to child signal FD: Invalid argument

I've seen that, I believe it's related to the stock Slackware build script. Build Emacs yourself according to the SlackBuilds in post #4 here (no native-comp) or #18 here (with native-comp, requires rebuilding gcc) and the issue should be gone.

Originally Posted by Petri Kaukasoina Which emacs is it? slackware64-15.0: patches/packages/emacs-29.3-x86_64-1_slack15.0.txz slackware64-current: e/emacs-29.3-x86_64-1.txz slackware64-current: extra/emacs-regular-build/emacs-29.3-x86_64-1_regular.txz

It is the first one, the patch that came to my attention last week.

Originally Posted by 3Tom It is the first one, the patch that came to my attention last week.

Recompile as above, and problem solved I can confirm from testing (with `emacs -nw -Q`) that stock Emacs 29.3 produces the "write to child signal FD: Bad file descriptor" error after M-x compile, whereas the recompiled ones do not.

In sum, this error seems to be some quirk in how Emacs is being built on Slackware.

Originally Posted by drgibbon I've seen that, I believe it's related to the stock Slackware build script. Build Emacs yourself according to the SlackBuilds in post #4 here (no native-comp) or #18 here (with native-comp, requires rebuilding gcc) and the issue should be gone.

Thank you, I'd like to try that. Downloaded the source from https://packages.slackware.com/ and tried to verify the gpg signature of the tarball and gpg said

> gpg: Can't check signature: public key not found

Searched slackware.com but couldn't find the key. Where can I get it?

And then: What does 'native-comp' mean? Is it only the terminal version of emacs invoced with -nw, or does it more than that? I'd like to have it, but it is not essential.

I do not understand why an emacs with more functionality (X window etc.) can be build with the gcc from the distro and apperently the part with less functionality requires another version of gcc.

Is there a simple explanation for that?

I once installed the multilib thing from alienbob on my system and it works well. And there was some recompiling for the mingw that is also on my system. Everything works well, but I've forgotten how everything is interrelated and I don't want to endanger things. Maybe I should stick with my alias emacs=emacs 2>/dev/null "solution" for now.

Is there a simple explanation for that?

Yes. In a word, developers. Each dev compiles code, and it usually works on present versions of gcc, but not necessarily on future ones.

By all means stick with your alias and get used to the fact that things that work might bellyache like mad because the developers like that feedback. It helps them find faults. If you think emacs is bad, wait until you start wine from a terminal!

Originally Posted by 3Tom Thank you, I'd like to try that. Downloaded the source from https://packages.slackware.com/ and tried to verify the gpg signature of the tarball and gpg said > gpg: Can't check signature: public key not found Searched slackware.com but couldn't find the key. Where can I get it?

You need the key for the person who signed the release archive for Emacs (nothing to do with Slackware):

gpg2 --verify emacs-29.3.tar.xz.sig
[...]
gpg: Good signature from "Eli Zaretskii <eliz@gnu.org>" [unknown]

Originally Posted by 3Tom And then: What does 'native-comp' mean? Is it only the terminal version of emacs invoced with -nw, or does it more than that? I'd like to have it, but it is not essential.

It can lead to faster Emacs in some aspects, but just search it up and decide if you want it or not.

Originally Posted by 3Tom I do not understand why an emacs with more functionality (X window etc.) can be build with the gcc from the distro and apperently the part with less functionality requires another version of gcc.

I don't know what you mean, if you want the native-comp feature on Slackware you will need to recompile gcc, but you can also just ignore it. Both build scripts above will give a GUI and terminal version of Emacs.

Originally Posted by 3Tom Maybe I should stick with my alias emacs=emacs 2>/dev/null "solution" for now.

You can quite easily build Emacs with the build script here, no native-comp/gcc messing around, and the problem will be fixed properly.

Originally Posted by business_kid Yes. In a word, developers. Each dev compiles code, and it usually works on present versions of gcc, but not necessarily on future ones. By all means stick with your alias and get used to the fact that things that work might bellyache like mad because the developers like that feedback. It helps them find faults. If you think emacs is bad, wait until you start wine from a terminal!

Thanks for this enlightening meta-persepctive!

Finally I found the key (is is on savannah.org what makes sense..) but decided to stick with the alias.

slackware64-15.0/ChangeLog.txt

Tue Apr 23 19:48:05 UTC 2024
patches/packages/emacs-29.3-x86_64-2_slack15.0.txz:  Rebuilt.
  This is a bugfix release.
  Only build the X11/GTK+3 version. Use "emacs -nw" if you want to start it
  in a terminal emulator in text mode, or rebuild if you really need to get
  rid of the X11 dependency for some reason.
  Build using --with-pdumper=auto. It seems that --with-dumping=unexec produces
  a buggy Emacs here in the modern era, with symptoms such as "child signal FD:
  Invalid argument". It's possible this had something to do with the reported
  memory leaks as well.
  Thanks to 3Tom for the bug report.

Originally Posted by Petri Kaukasoina slackware64-15.0/ChangeLog.txt Tue Apr 23 19:48:05 UTC 2024 patches/packages/emacs-29.3-x86_64-2_slack15.0.txz: Rebuilt. This is a bugfix release. Only build the X11/GTK+3 version. Use "emacs -nw" if you want to start it in a terminal emulator in text mode, or rebuild if you really need to get rid of the X11 dependency for some reason. Build using --with-pdumper=auto. It seems that --with-dumping=unexec produces a buggy Emacs here in the modern era, with symptoms such as "child signal FD: Invalid argument". It's possible this had something to do with the reported memory leaks as well. Thanks to 3Tom for the bug report.

The crashes I reported are gone with this update.

Thanks Petri, the error-messages are gone!

Ah nice, fixed in the main branch, thanks Pat!