这问题在旧版OSX上挺典型的，你已经排除了SHMAX、SHMSEG和键冲突这些常见坑，那接下来可以从以下几个方向深入排查：

• 检查SHMMIN与段大小的对齐限制
  OSX的SysV共享内存实现有个容易被忽略的细节：当请求的内存段大小介于SHMMIN（最小段大小）和SHMLBA（内存对齐边界，通常等于页大小）之间时，系统可能仅允许使用SHMMIN的精确值，而非任意大小。你可以先通过以下命令查看这两个参数：

  sysctl kern.sysv.shmmin kern.sysv.shmlba
  

  如果shmmin返回4，shmlba返回4096（OSX 10.13的默认值），那这就是问题根源——系统不允许创建大小在4到4095之间的共享内存段，要么用最小的4字节，要么直接申请页大小的整数倍（比如4096字节）。你可以试试申请4096字节的段验证这一点。

• 核对shmget错误码的具体触发条件
  虽然报错是"Invalid argument"，但你可以在代码里打印更精确的错误信息，或者直接查看OSX的shmget手册页（执行man shmget），重点看EINVAL错误的触发场景。在OSX 10.13中，EINVAL除了超出SHMAX/SHMMIN的情况，还可能隐含段大小不符合系统对齐规则的限制——这一点在Linux的实现中通常更宽松，但OSX的SysV共享内存兼容性有限。

• 验证页大小整数倍的申请是否正常
  直接写个测试代码，申请4096字节的共享内存段：

  test_shmid = shmget(foo_key, 4096, IPC_CREAT | 0666);
  

  如果这个能成功，那基本可以确认是小尺寸段的特殊限制导致的问题。OSX对SysV共享内存的小尺寸支持非常有限，更推荐你直接使用页大小作为最小申请单位，或者考虑改用更符合OSX生态的内存共享方案（比如Mach端口的内存对象，或者mmap文件映射）。

• 检查系统是否有其他隐藏限制
  旧版OSX可能对SysV共享内存有一些未公开的限制，你可以通过sysctl -a | grep kern.sysv查看所有相关参数，确认有没有其他和段大小相关的配置项被意外修改过。不过根据你的描述，最可能的还是前面提到的对齐/最小段大小限制。

内容的提问来源于stack exchange，提问作者Rustang