最近在做xvector（kaldi sre16 v2）相关的实验，遇到各种烦心的事情。谨以此文纪念烦了我几天才解决的一个问题。
“血案”的过程大致是这样：
get_egs.sh 中执行 nnet3-shuffle-egs 时，线程莫名死掉（killed）。
分析一波日志，也看不出有什么问题，查看硬盘情况也没有爆，那就重跑一下，观察一下是否内存爆了。
果不其然真的是内存爆了。
阅读了一波脚本，这个是可以解决的，在 nnet3-shuffle-egs 调用时加上参数 buffer-size ，控制一下。
但刚开始没经验，这个值设置太大（20，000，000；我当时以为是以KB为单位，想想开20G左右机器也吃得消）。
结果还是一样，我就觉得是不是参数没有生效，所以就到 kaldi/src/nnet3bin/nnet3-shuffle-egs.cc 加各种 log（当时也没多想就#include <iostream> std::cout<< ...）。
编译通过，重跑，发现参数生效了，后面看代码发现这个 buffer-size 实际上是 vector size，所以就把它调小，减掉一个0（2，000，000），发现OK了，内存不爆了！
跑跑跑，又挂了，这回发现是硬盘爆了。。。好吧，写个脚本定期检测中间文件使用情况，用完就删了，硬盘问题也得以解决； nnet3-shuffle-egs 完美跑通。
前期数据准备工作搞完，是时候该train了吧，结果帅不过3秒，train的时候又莫名的（core dumped）。。。
看了各种日志，一点有用的东西都没有。。。
刚开始以为是GPU被占用，几个方法看了下，并没有；然后重新编译src（中间有听说周末公司整服务器，以为设备换了，需要重新编译），还是不顶用。
中间看到过一个日志报申请一个大空间失败，以为是数据集过大，换回之前训练成功的数据集（包括数据量明显比报错的数据集小的训练集），发现，也不行了。。。。
这就让我产生怀疑（心态爆炸）。。。感觉不应该啊，所以回头看是不是（不小心）改了哪里导致。
回头各种 git status/diff 查看自己的修改，发现并没有“不小心”的修改，自认为这些修改并不会导致（core dumped）吧。
shell脚本各种恢复发现都不行，最后到C++，好在C++代码改动不大；注释 kaldi/src/nnet3bin/nnet3-shuffle-egs.cc 各种 log（#include <iostream> std::cout<< ...）；重新编译。
发现居然。。。。。。居然。。。。。。。解决了。。。。。。。。。
继续实验。。。
谨以此文，来释放一下我这几天郁闷的心情！
同时希望能（万一）有大神看完我啰嗦半天，还能告诉我 cout 引发的血案的原理的话，感激不尽。。。。。
明天要写周报，又开始担心我这周的工作量了。。。。。。溜了溜了，回去搬砖。。。
（我能把我这周的曲折踩坑历程写上去吗。。。。。。。）