当应用程序已在运行，或无法正常退出并继续在后台运行时，就会发生这种情况。
试试看：

$ pkill <yourappname>

错误消息flock failed to lock maps file: errno = 35或（list）表示对flock()的调用失败，错误代码为35，在某些系统上对应于EAGAIN，在macOS上也是如此。如果文件的锁被另一个进程持有，或者该进程已达到其最大锁数，则会发生此错误。
一个典型的症状是这个错误信息在你的日志中出现了很多次。2这也指出了为什么它会出现这么多次的一个可能的原因。3但是这是另一个关于flock（）内部工作的讨论。
若要调试此问题，您可以尝试确定哪个进程正在持有锁。在“终端”中，您可以使用lsof命令列出所有打开的文件以及打开这些文件的进程。例如：

$ lsof | grep maps

这将花费几秒钟的时间，并为您提供一个打开Map文件的进程列表。从该列表中，您可以尝试使用进程ID（PID）和flock命令来确定哪个进程持有锁。例如：

$ flock -x -w 10 /proc/<PID>/maps

如果flock命令成功，则持有锁的进程已经释放了锁;如果flock命令失败，则可以尝试杀死持有锁的进程。
不错的一个，但如何找到PID？更多关于这一点下面。
因此，以下做法可以称为“残酷”做法：
如果你用flock()在C++中编写代码（当你使用pipe机制时也是如此，因为这可能会干扰/dev/null，这是一个文件的特殊情况，并使用fork()，dup()，dup2()，shmget()和类似的调用），不知何故，你的锁定/解锁机制弄乱了你的Map，这是锁被写入的地方，那么pkill肯定会帮你解决这个问题。但是在这样做之前，证明有多个进程具有相同的名称-你会知道名称应该是什么样子的，因为你自己编写了它。
如果您知道名称，可以使用pgrep查找所有示例。

pgrep -x myappname

myappname确实在Map列表中吗？如果是，继续，上面的这个命令将打印一个PID列表，它对应于这个进程名，通常对应于应用程序名。
从这里你可以，这就是为什么我命名它 * 残酷 *，只是pkill所有与

pkill -x myappname

当然，这会迫使所有的线程立即退出，这反过来也会释放它们可能仍然持有的文件的锁。但是要注意，pkill-ing并没有正确地释放，它只是立即退出，所以在-dealloc方法中编码的flock unlock也不会触发，但使用的内存会被释放-这正是你所需要的。

• 为什么会发生这种情况？您可能只是在开发过程中崩溃了应用，或者打开了Metal调试，当然在管道日志示例中也使用了这种机制。当您在没有正确执行dealloc或类似操作的情况下退出时，可能不会调用清理进程来释放文件锁（简称：flock）到某个文件或管道，因此该文件保持锁定。*

由于Xcode with Metal调试会尝试设置一个锁到它的Map文件，但是在你每次尝试设置一个锁到一个锁定的文件之前，这个文件已经被锁定了，因为它是崩溃遗留下来的。所以如果这是原因的话，仅仅关闭Metal调试是没有意义的。你仍然需要解锁僵尸应用程序/进程仍在使用的文件。自己擦除Map文件就像直接扰乱文件系统，当然会导致惊喜。
也

df -l

我应该给予你一个你的文件系统的列表，你可以在那里看到多少使用信息是用掉了。在100%使用/dev/null和类似的情况下，你可以看到你是否搞砸了共享内存，在这种情况下，当你试图在一个用完的内存上获取一些文件时，解锁文件的聚集也会失败。如果这一切都是通过使用管道机制发生的，你很可能没有刷新你的缓冲区 aka 你没有从它读取，这反过来应该清空这样的缓冲区，所以它不能锁定的情况下，它变得充满。
如果所有这些都没有帮助-你最后的手段是重新启动机器。

它通常会指向一个带有列表的文件。删除它，你应该很好。