Since the last dozen or so nightlies, Emacs has stopped being able to run subprocesses with a PTY attached, as vfork fails with “Invalid argument”. I haven’t had the time to debug that in detail yet, but does anyone know if something changed to the fork/vfork implementation in Haiku over the past few weeks?
Thanks.
Looked at the git log for src/system up until last August, not much which could explain this. Maybe hrev56392 ?
If you haven’t cleaned up the previous packages, you can still boot older revisions from the boot menu, and try to pinpoint which one started to break.
Could you give me a link to that commit or something? I’m not quite sure how to look up an hrev number in the repository.
It’s there, so this commit. Possibly some pages can’t be copied properly after this change when forking?
That doesn’t seem to be the case. It really just started happening in the last week or so, so within the last few nightlies.
I won’t have the time to look through everything and find exactly which nightly caused it for at least the next several weeks, so if someone else knows what might be going on I’d appreciate it if he came forth with that information.
Thanks in advance.
Might it be Haikuports related? I know bash_completion has been “fixed” on 22th.
Unfortunately Emacs calls `vfork’ directly, so it can’t be related to bash_completion, as bash doesn’t even have a chance to start when the error is reported. I mentioned PTYs as Emacs calls posix_spawn when a PTY is not attached, which doesn’t fail with EINVAL.
Note that Haiku does not have a real vfork; it just invokes the regular fork (and has always done so, not a recent change.)
I don’t know of any recent changes either. Do you know what hrev you were on that last worked, and what one you are on now?
Can you run strace (maybe with some arguments needed if the fork is invoked by a thread other than the main) to see what syscall is returning that error?
Bisecting via nightly images shows the problem starting after hrev56460. I saw a warning when building emacs about the functions referenced in hrev56465 so I’m suspicious of that one.
Could be that. Debugging shows the error happens in posix_spawnattr_setflags (but not the _np) variants, which is called like this:
error = posix_spawnattr_setflags (attributes,
POSIX_SPAWN_SETSID
| POSIX_SPAWN_SETSIGDEF
| POSIX_SPAWN_SETSIGMASK);
it turns out I was wrong about when the bug rears its head; it happens when the posix_spawn codepath is used, but the error message printed by Emacs in that case is misleading (which I will fix.)
BTW, I should’ve fixed the build warnings now. Not sure if posix_spawn still fails.
Edit: nope, it still fails.
Reverting hrev56465 in my local build of Haiku fixes the problem for me. I am building from the haikuports repository so the emacs commit is a couple of weeks old. I haven’t tried the latest git master of emacs with your changes.
Not sure why only some of the functions in that .cpp is marked extern “C”. Probably all should be?
Right, then I guess that’s the problem. Does anyone want to submit a bug report? (If not, I’ll do it, but my time is somewhat limited.) My change was limited to fixing the build warning.
This commit isn’t exactly the problem. To me it looks like it triggers the use of posix_spawn in the emacs build.
It could actually be a simple fix: it seems
POSIX_SPAWN_SETSID is missing on the line spawn.cpp\posix\libroot\system\src - haiku - Haiku's main repository
Yes, that’s probably what happened. Wasn’t posix_spawn_file_actions_addchdir already present before though?
Yes, but it wasn’t exported properly so the symbol would not have been detected before that.
Thanks for fixing that.