一个只在系统集成环境下随机概率很低的crash问题(s11)的解决

1, 程序只在集成运行环境下才能复现,  如果在专门布置的环境下, 单独运行就不能复现; 此时, 我们只是注意到集成环境,是由一个agent进程对程序进行启动, 而单独运行情况下,是手动用shall进行启动, 但是进行调用环境方面的考虑, 但是却忽略一个方面的问题-数据准备方面: 单独手动调用的情况下,都是准备好所有需要用到的各类数据,放到确定的目录后便不再移动,并且可以事先确认数据是没问题的;但集成环境下,忽略了一个问题就是, 程序执行的需要的数据并不是直接从源头获取的,而是经过参与调度和环境部署的程序的移动的, 也就是说, 和单独手动执行根本的区别是,数据是经过移动而来的,不是原始位置确认没有问题的数据; 这也正是出问题的点:

    集成环境的调度进程中,会检查一个目录下是否已经有满足条件的三个文件同时存在(这里不用管是什么样的三个文件), 而这三个文件是由远程通过scp拷贝来的,其中有一个很大的二进制文件,比如1G左右的二进制文件,而scp不会等文件传输完就会建立对应的文件名在目录下面,如果用ls看,这个文件只是size一直在增长,因此,实际上会发生当文件还没有传输完的情况,调度进程发现已经满足的了三个文件的条件而用mv命令把文件移到程序访问的目录去了,这时候,喂给程序的数据中,大二进制文件实际上就是一个不完整的文件;

2, 二进制文件的设计和读写;

一般情况下,二进制文件的解析就是依靠其格式的协议, 有些二进制文件的访问所需的任何信息,也就是说,说明二进制文件任何一个字节的说明信息都集中在文件的头部,那这样的话,load文件头部就不会有问题, 但这时应该注意,load二进制文件,检查文件完成性, 头部信息一定能够反应文件的大小的最小值(因为文件末尾可能有写信息只是填充的作用);

    如果不能完成的load二进制文件的情况, 那就是流的情况下,流协议比如网络媒体流协议下,二进制数据就支持支持流入,缓存和处理的情况;

3, 之前遇到的随机问题,多数情况下都是自己的程序在很细微的地方,或者某个参数的使用上, 主要还是需要对程序整个流程的每个细节的检查上;现在到了集成环境下,不仅要考虑程序每个细节, 整个集成环境下程序所需数据的整个处理流程也要引起注意, 不能存在破坏数据的情况;

4, 之前我们理解随机问题还会怀疑是别人写的程序造成了内存访问越界修改了我们写的程序的数据,但一我个人的经验来看,内存被踩情况一般保存的范围不会超出一个函数,所以遇到断错误的情况,还是多怀疑自己程序涉及到的范围,代码,访问的数据等等;