Erlang 如果有受监控的端口，干净地停止一个监控子树会杀死VM；为什么？

我有一个elixir应用程序，其中有一个简单的1对1主管，其子女是1对1主管，该主管有许多工人。像这样：

------------------
|  SupSup (s141) |
------------------
        |
        |-------------------------------------- ...
        |                      |
------------------    ------------------
|    Sup (141)   |    |    Sup (141)   |        ...
------------------    ------------------
    |        |            |        |
----------            ----------
| Worker |  ...       | Worker |  ...           ...
----------            ----------

一些工作进程具有到外部进程的Erlang端口（使用

创建）。应用程序需要在树的
Sup
级别停止子树。执行此操作的代码（在
Worker
中运行）是
spawn（fn（）->Supervisor.terminate_child（Sup，pid）end）
其中
pid
是Worker的Sup的pid（通过
：gproc
查找）

在Fedora 24上，使用
Supervisor.terminate\u child（）
会导致Erlang VM崩溃：

erl_child_setup closed

Crash dump is being written to: erl_crash.dump...done

在Ubuntu16.04上，没有崩溃，子树按预期干净地退出

为什么?

这是一个相当复杂的情况，因此粘贴整个应用程序是不合适的。我把复制问题所需的一切都放在了GitHub的Fedora 24崩溃转储中

编辑1：在Fedora上，环境是OTP 19.2/Elixir 1.4.1，采用Kell和kiex建造。在Ubuntu上，Erlang和Elixir是19.1/1.4.0-1，并与来自Erlang解决方案的apt get一起安装

编辑2：删除Ubuntu上的Erlang和Elixir并用Kell和kiex重新安装19.2/1.4.1并没有改变结果：Ubuntu上没有VM崩溃。
如果这只发生在Fedora上，我会说这是Fedora的Erlang或Elixir包的问题。尝试在Fedora上从源代码处编译Erlang和Elixir，看看是否仍然存在相同的问题。您是否在两个系统上运行相同版本的Erlang？19.1中类似错误的bug似乎已修复：。我用dev环境更新了该问题data@Clay你能在两个系统上用相同的版本运行这个吗？Dogbert我重新编辑了这个问题——Ubuntu上的19.2/1.4.1仍然像预期的那样工作。如果这只发生在Fedora上，我会说这是Fedora的Erlang或Elixir包的问题。尝试在Fedora上从源代码处编译Erlang和Elixir，看看是否仍然存在相同的问题。您是否在两个系统上运行相同版本的Erlang？19.1中类似错误的bug似乎已修复：。我用dev环境更新了该问题data@Clay你能在两个系统上用相同的版本运行这个吗？Fedora上的19.1版本和/或Ubuntu上的19.2版本。@Dogbert我重新编辑了这个问题——Ubuntu上的19.2/1.4.1版本仍按预期运行