Python node2vec（Gensim Word2Vec）“进程结束，退出代码为134（被信号6:SIGABRT中断）”

Question

我正在用Python开发node2vec，它在内部使用Gensim的Word2Vec

当我使用小数据集时，代码运行良好。但当我试图在大型数据集上运行相同的代码时，代码就会崩溃

Error: Process finished with exit code 134 (interrupted by signal 6: SIGABRT).

给出错误的行是

model = Word2Vec(walks, size=args.dimensions,
                 window=args.window_size, min_count=0, sg=1,
                 workers=args.workers, iter=args.iter)

我正在使用pycharm和python 3.5

知道发生了什么吗？我找不到任何能解决我问题的职位

Answer 1

我也有同样的问题，最后我找到了答案。我的原因是我的Keras{}太高了。 之后，我将版本更改为2.0.1，它就工作了。 希望这个版本能对你有所帮助

Answer 2

对我来说，问题在于MacOSCatalina上运行的雪花连接器Python库

我在回答59538581中给出的链接中找到了用户VikR的解决方案，该链接已从此页面中删除

链接是https://dbaontap.com/2019/11/11/python-abort-trap-6-fix-after-catalina-update，标题是Danny Bryant的“Python中止陷阱：Catalina更新后的6修复”。该链接解释了SSL库需要放回Mac的操作系统路径，并给出了执行步骤。它还列出了使用brew和pip3升级库的步骤

下面是我再次运行Python脚本所遵循的步骤

brew update
brew upgrade
cd /usr/local/lib
ln -s /usr/local/Cellar/openssl\@1.1/1.1.1j/lib/libssl.1.1.dylib libssl.dylib
ln -s /usr/local/Cellar/openssl\@1.1/1.1.1j/lib/libcrypto.1.1.dylib libcrypto.dylib
pip3 install --upgrade snowflake-connector-python

对我来说，我不必安装openssl，因为我已经安装了它。请阅读布莱恩特的page了解更多细节

注意

1. 我对openssl的理解当然比科比的指示要晚。与我在这里使用的版本相比，您的版本也很可能更晚
2. 自制的/Cellar/目录结构对我来说与科比写指令时略有不同。当你读到这篇文章时，它可能又变了
3. 我选择直接链接图书馆，而不是像Bryant那样链接图书馆的副本
4. 我的自制/Cellar/和/usr/local/lib文件夹实际上需要大量的用户所有权更改。由于这与最初的问题无关，我省略了这些步骤

Answer 3

几乎可以肯定的是，您的内存已经用完了，这会导致操作系统使用SIGABRT进程中止您的内存

一般来说，解决这一问题意味着查看代码是如何使用内存的，在出现故障之前和出现故障时是如何使用内存的。（然而，过量大容量内存使用的实际“泄漏”可能是任意提前的，只有最后一个小的/适当的增量触发错误。）

特别是使用Python和利用Gensim Word2Vec类的node2vec工具时，需要尝试的内容包括：

在尝试过程中，观察Python进程大小的读数

至少在INFO级别启用Python日志记录，以了解导致崩溃的更多信息

此外，请确保：

1. 优化你的walks表以而不是组成一个大的内存列表。（Gensim的Word2Vec可以在任何长度的语料库上工作，包括那些比RAM大得多的语料库，只要（a）语料库通过可重写的Python序列从磁盘流式传输；（b）模型中的唯一单词/节点标记的数量可以在RAM中建模。）
2. 确保模型中唯一字（令牌/节点）的数量不需要大于RAM允许的模型。日志输出一旦启用，将在主模型分配（可能失败）发生之前显示所涉及的原始大小。（如果失败，可以：（a）使用具有更多RAM的系统来容纳整个节点集；或者（b）或者使用更高的min_count值来丢弃更不重要的节点。）

如果Process finished with exit code 134 (interrupted by signal 6: SIGABRT)错误不涉及Python、Gensim和&Word2Vec，您应该：

1. 搜索该错误的发生情况，并结合您的触发情况的更具体细节-创建错误的工具/库和代码行
2. 查看适用于您的情况的常规内存分析工具，以确定代码可能在何处（甚至在最终错误之前很久）消耗几乎所有可用RAM