cosmopolitan: MacOS 12.4 Bad system call: 12

This is an amazing project! I’m having trouble getting it running on my Mac. I was worried zip or Gatekeeper were corrupting the file somehow, but now I am thinking I just may not understand how to run it on MacOS. Please see output below.

OS: macOS Monterey 12.4 (Gatekeeper Disabled), Intel

curl https://redbean.dev/redbean-latest.com.dbg >redbean.com.dbg

file redbean.com.dbg 
redbean.com.dbg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped

chmod +x redbean.com.dbg

./redbean.com.dbg 
bash: ./redbean.com.dbg: cannot execute binary file

./redbean.com.dbg --assimilate
bash: ./redbean.com.dbg: cannot execute binary file

alternatively

curl https://redbean.dev/redbean-latest.com >redbean.com

file redbean.com
redbean.com: DOS/MBR boot sector

chmod +x redbean.com

./redbean.com
Bad system call: 12

./redbean.com --assimilate

file redbean.com
redbean.com: Mach-O 64-bit executable x86_64

./redbean.com
Bad system call: 12

I hope this isn’t a waste of your time, I didn’t see anyone else from the 2.0 release thread on HN have this issue, though there were some similar problems on the original Show HN that didn’t help me.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 17 (8 by maintainers)

Commits related to this issue

Polyfill sched_yield() on XNU We were using the Mach system call swtch() earlier. It's possible Apple removed this system call in their recent 12.4 upgrade. We're better off using x86 PAUSE here, sin... — committed to jart/cosmopolitan by jart 2 years ago
Don't use vfork() on XNU (#426) — committed to jart/cosmopolitan by jart 2 years ago

Most upvoted comments

redbean-2.0.2 now available at https://redbean.dev/2.0.html

jart on Jun 17, 2022

Hi @jart , for me it fixed the problem:

curl https://redbean.dev/redbean-issue426.com >redbean.com
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1987k  100 1987k    0     0  1082k      0  0:00:01  0:00:01 --:--:-- 1086k

chmod +x redbean.com

./redbean.com -v
I2022-06-17T04:10:31.391340:tool/net/redbean.c:6923:redbean:5236] (srvr) listen http://127.0.0.1:8080
I2022-06-17T04:10:31+000054:tool/net/redbean.c:6923:redbean:5236] (srvr) listen http://192.168.0.152:8080
I2022-06-17T04:10:31+000026:tool/net/redbean.c:6923:redbean:5236] (srvr) listen http://10.70.31.188:8080
V2022-06-17T04:10:31+000133:tool/net/redbean.c:1857:redbean:5236] (ssl) could not find non-CA SSL certificate key pair with -addext keyUsage=digitalSignature -addext extendedKeyUsage=serverAuth
V2022-06-17T04:10:31+000006:tool/net/redbean.c:1860:redbean:5236] (ssl) could not find CA key signing key pair with -addext keyUsage=keyCertSign
V2022-06-17T04:10:31+000002:tool/net/redbean.c:1862:redbean:5236] (ssl) generating self-signed ssl certificates
V2022-06-17T04:10:31+001326:tool/net/redbean.c:610:redbean:5236] (ssl) using EC certificate "CN=localhost" for HTTPS server
V2022-06-17T04:10:31+057612:tool/net/redbean.c:610:redbean:5236] (ssl) using RSA certificate "CN=localhost" for HTTPS server

sszachow on Jun 17, 2022

Part of what makes Cosmopolitan so interesting is we’re able to build 12kb binaries that run on seven operating systems. If we were required to always use dynamic shared objects on Mac OS then it would destroy much of what we’ve accomplished.

I believe Apple is being unfair. The binary interface for UNIX SYSCALLs is something Apple inherited from the System V codebase (e.g. 1 for exit, 3 for read, etc.). They shouldn’t consider something like that an internal API, when it’s shared by so many operating systems.

THEREFORE please be advised there is some risk you may need to rebuild your binaries if Apple breaks the system call interface again. I have no commercial interest in distributing Cosmopolitan binaries. I’m just an open source developer trying to help out. I’d rather be focusing on improving the product than worrying about what appears to be a disagreement between two megacorps.

When Apple broke gettimeofday() they effectively smashed all of Google’s toys. So far there’s no indication something that drastic will happen again. swtch() and vfork() are things I could have predicted since the first is totally non-essential Mach and the latter was removed from POSIX a while ago. I’ve also added to redbean automated error reporting facilities now which trap SIGSYS and inform us in RBX of the precise system call that broke the moment it happens so it can be fixed quickly and easily. I believe that over time we will converge on a stable subset of SYSCALLs that Apple won’t unintentionally break.

Just please be advised there may be some bumps along the way.

jart on Jun 25, 2022

@jart Redbean 2.0.7 now shows -h just fine, forks ‘less’ successfully., thanks!

Btw, my Mac is running 12.4 Monterey, uname -a reports ‘Darwin Kernel Version 21.5.0, Tue Apr 26 21:08:22 PDT 2022’

tpoindex on Jun 24, 2022

@jart Wanted to double confirm that it’s working for me as well. Thank you for your diligence with this!

elamje on Jun 17, 2022

It looks like the issue might be with sched_yield. I’ve pushed a commit that I believe will fix this. Could you please try downloading https://redbean.dev/redbean-issue426.com and letting me know if that fixes the issue? Alternatively, you could build this repo with the latest change from HEAD. Thanks!

jart on Jun 17, 2022

This is a high priority item. I monitor the XNU syscalls.master file and I haven’t seen any changes that would indicate a breakage. I’m running MacOS 11.6.5 right now and I don’t have access to a v12.4 machine.

Could you please try running ./redbean.com --strace and ./redbean.com --ftrace and let me know what it says?

It would also help if someone could open the executable in a debugger, and let me know what the value of RAX register is when it falts on the SYSCALL instruction. Basically, I need to know which system call Apple isn’t allowing.

Alternatively, you can grant me SSH access to an apple machine running this version. My SSH keys are in https://github.com/jart.keys

jart on Jun 17, 2022