程序在并行的时候出现下面的错误,单核运行没有错误



  • *** Error in ' DFrhoCentralFoam ': corrupted double-linked list: 0x0000000002069690 ***
    [UbuntuL08311] *** Process received signal ***
    [Ubuntu: 08311] signal: Aborted(6)
    [Ubuntu: 08311] signal code: (-6)
    下面是一样的,就是list后面的数字不一样,请问有谁遇到过这样的错误吗?网上看了一下说是内存错误,不晓得怎么回事?谢谢~



  • Hi,目前还没遇到过这种情况:expressionless:


  • OpenFOAM教授

    请给出完整错误信息。





  • @李东岳 好的,谢谢。
    我试着在服务器上运行一下并行,出现的错误是这个,和之前在Ubuntu上的不一样
    0_1460984161516_1.jpg
    我想可能的原因如下:
    我的代码里用到了读文件的语句,是在INLET边界处,将txt文件中的数据逐一赋值到INLET的faces,我想simple方法分块之后,有的processor的INLET是有面的,有的是没有面的,比如第N个proccessor中INLET的face数为0,是不是可能导致出错?


  • OpenFOAM教授

    @Aeronastro程序在并行的时候出现下面的错误,单核运行没有错误 中说:

    有的processor的INLET是有面的,有的是没有面的,比如第N个proccessor中INLET的face数为0,是不是可能导致出错?

    你赋值的时候是如何遍历的?



  • @wwzhao 在程序中,我先用findPatchID("INLET")找到这个边界ID,得到这个边界,将面心提取出来。从文件中读取数据(实际上相当于数据库),根据坐标插值得到对应面心的值。face从0开始一直到这个边界face的size结束。


  • OpenFOAM教授

    @Aeronastro

    思路没问题,建议你用OpenFOAM的mpirunDebug来调试并行程序。



  • @wwzhao 好的,谢谢,Debug模式下的操作我还没有用过,能教教我吗?我的求解器已经用Debug模式编译过了,运行mpirunDebug之后,选择了gdb+Xterm方式,我的processor是0~7,跳出了8个xterm窗口,里面的内容有7个processor是一样的,如下图:0_1461070226438_截图.png
    我不太清楚之后怎么做
    还有一个processor,是这样的,如下图:
    0_1461070402883_截图2.png
    谢谢指导!



  • @wwzhao 我用xterm+valgrind模式进行调试,内容会多一些:
    Memcheck, a memory error detector!是不是出现了内存错误
    0_1461079176650_截图3.png
    但这要怎么改呢?我的求解器是基于OF中的自带的求解器加了一点内容,上面的错误好像没有提到我自己编的地方

    这个图是一部分内容

    我看到错误内容除了Invalid read of size 8之外,还有conditional jump or move depends on uninitialised value(s),4 bytes in 1 blocks are still reachable in loss record 1 of 4267,这里的1会一直增加,2 of 4267;3 of 4267 ....不知道这里的4 bytes是哪里的,可能没有释放掉。


  • OpenFOAM教授

    从backtrace来看似乎是堆内存溢出引起的,你用了operator new操作符吗?



  • @wwzhao 我没有用到operator new操作符。

    我大部分代码还是of自己的,额外加的地方就是定义了两个类,两个个函数和一些全局变量,如下图:
    0_1461119717673_截图.png
    单核运行是可以的话,代码应该问题不大吧?

    前两个是定义的两个类,第三个是一些变量(相当于全局变量),最后两个是定义的函数。为了方便,我都写成了#include 。

    上面的Invalid read of size 8的错误我在OF自己的求解器并行算了一下,还是有这个,但是可以运行。我想应该不是我代码本身的问题。虽然不知道是什么原因,但这个错误应该不至于我的求解器算不下去。

    我想问题就出现在了我之前提到的另外的那个错误,类似于4 bytes in 1 blocks are still reachable in loss record 1 of 4267。


  • OpenFOAM教授

    processor0.log的内容为0号进程(master)的输出,所有用Info语句打印的字符串都会输出到这个文件里,从gdb的调试输出看,程序似乎在after :-0.281567...... 这句之后就奔溃了,不知道你的程序具体做了什么操作。

    建议你一步一步定位到出问题的语句,然后想办法解决。Good luck!



  • @wwzhao 谢谢你的建议,昨天我试着找了一下。关于并行计算,各个processor都要执行求解器的.C文件,而我的求解器的一些语句并不完全适合于每个processor,其中就是找INLET边界,读出面心值,然后对面心值进行操作。我的分块中只有processor0的INLET有面,即nFaces不是0,其余processor的INLET的nFaces都是0,如果对面为0的processor做这样的面心操作,是不是就有问题?所以我加了判断语句之后,processor1,2,3...就没有那个问题了,但是在processor0又出现新的问题,我还在找。
    不知道我上面说的对不对


  • OpenFOAM教授

    你说的没错,MPI是分布式内存,同一个变量名在不同进程中的值很可能不一样,因此在处理并行时要特别注意。


Log in to reply