程序正常崩溃但不是Valgrind

时间:2016-11-15 03:46:03

标签: assembly x86 gdb 64-bit valgrind

我正在尝试调试一个程序集程序(x86 64-bit),并根据gdb信息,在使用以下指令时崩溃:

xorpd  0x1770(%rip),%xmm12        # 0x40337c <S_0x403230>

然而,在我看来,记忆0x40337c是完全正常的:

(gdb) x /10x 0x40337c
0x40337c <S_0x403230>:  0x00000000      0x80000000      0x00000000      0x00000000
0x40338c <S_0x403240>:  0xf149f2ca      0x00000000      0x746e7973      0x203a7861
0x40339c <S_0x403248+8>:        0x206d626c      0x6d69743c

另一个有线的事情是,当我在命令行以及gdb内运行时,这段代码每次都会崩溃。但是,当我在valgrind中调试它时,它不会崩溃!

☁  src [master] ⚡ valgrind ./a.out 20 reference.dat 0 1 100_100_130_cf_a.of
==18329== Memcheck, a memory error detector
==18329== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==18329== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==18329== Command: ./a.out 20 reference.dat 0 1 100_100_130_cf_a.of
==18329==
MAIN_printInfo:
    grid size      : 100 x 100 x 130 = 1.30 * 10^6 Cells
    nTimeSteps     : 20
    result file    : reference.dat
    action         : nothing
    simulation type: channel flow
    obstacle file  : 100_100_130_cf_a.of

LBM_showGridStatistics:
   nObstacleCells:  498440 nAccelCells:       0 nFluidCells:  801560
  minRho:   1.0000 maxRho:   1.0000 mass: 1.300000e+06
 minU: 0.000000e+00 maxU: 0.000000e+00

LBM_showGridStatistics:
  nObstacleCells:  498440 nAccelCells:       0 nFluidCells:  801560
  minRho:   1.0000 maxRho:   1.0431 mass: 1.300963e+06
  minU: 0.000000e+00 maxU: 1.272361e-02

==18329==
==18329== HEAP SUMMARY:
  ==18329==     in use at exit: 0 bytes in 0 blocks
 ==18329==   total heap usage: 4 allocs, 4 frees, 428,801,136 bytes allocated
 ==18329==
==18329== All heap blocks were freed -- no leaks are possible
==18329==
==18329== For counts of detected and suppressed errors, rerun with: -v
==18329== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

如果您感兴趣,我在here上传了二进制代码供您参考。汇编程序实际上是由二进制重写器生成的,我曾经能够生成无错误的代码。所以我相信这可能不是一个难以调试的指针解引用问题,应该是很容易修复的东西。但是,我真的不知道哪里出错了,而且在gdb调试中似乎完全正常({{1 }})

所以这是我的问题,

  1. 给出调试信息(x/10x 0x40337),哪里可能出错?

  2. 为什么二进制代码不会在x/10x 0x40337c中崩溃?

1 个答案:

答案 0 :(得分:3)

Valgrind runs your code on a simulated x86 CPU。显然它没有模拟对齐检查。

SSE指令的128位和更大内存操作数总是需要自然对齐。 (例如,对于像这样的16B负载的16B边界)。例外是MOVUPS_mm_loadu_ps)(和MOVUPD / MOVDQU)。

0x40337c不是16B对齐,只有4B。 (因此,您在XORPD中使用它时非常奇怪,因为我期望double至少有8B对齐。

AVX指令正好相反:默认情况下不需要对齐,但VMOVAPS确实需要对齐。