2

我在使用可以简化为此示例的旧 Fortran 代码时遇到问题：

program main
implicit none
write(6,*) 'Hello!'
end program main

subroutine bigdata()
implicit none
!real*8 AA(50292712)
real*8 AA(50292713)
common /big_common/ AA
end subroutine

请注意，从不从程序中调用子例程。在 64 位机器上编译和运行它，给了我：

$ gfortran -fsanitize=address main.f ; ./a.out
 Hello!

$ gfortran -m32 main.f ; ./a.out
 Hello!

$ gfortran -m32 -fsanitize=address main.f ; ./a.out                                                                                                               
==32656== Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.
==32656== Process memory map follows:
        0x08048000-0x08049000   /home/username/a.out
        0x08049000-0x0804a000   /home/username/a.out
        0x0804a000-0x0804b000   /home/username/a.out
        0x0804b000-0x1ffff000
        0xf5d77000-0xf5d78000
        0xf5d78000-0xf5dbc000   /lib/i386-linux-gnu/libm-2.19.so
        0xf5dbc000-0xf5dbd000   /lib/i386-linux-gnu/libm-2.19.so
        0xf5dbd000-0xf5dbe000   /lib/i386-linux-gnu/libm-2.19.so
        0xf5dbe000-0xf5dbf000
        0xf5dbf000-0xf5e38000   /usr/lib32/libquadmath.so.0.0.0
        0xf5e38000-0xf5e39000   /usr/lib32/libquadmath.so.0.0.0
        0xf5e39000-0xf5e3a000   /usr/lib32/libquadmath.so.0.0.0
        0xf5e3a000-0xf5e56000   /lib/i386-linux-gnu/libgcc_s.so.1
        0xf5e56000-0xf5e57000   /lib/i386-linux-gnu/libgcc_s.so.1
        0xf5e57000-0xf5e5a000   /lib/i386-linux-gnu/libdl-2.19.so
        0xf5e5a000-0xf5e5b000   /lib/i386-linux-gnu/libdl-2.19.so
        0xf5e5b000-0xf5e5c000   /lib/i386-linux-gnu/libdl-2.19.so
        0xf5e5c000-0xf5e74000   /lib/i386-linux-gnu/libpthread-2.19.so
        0xf5e74000-0xf5e75000   /lib/i386-linux-gnu/libpthread-2.19.so
        0xf5e75000-0xf5e76000   /lib/i386-linux-gnu/libpthread-2.19.so
        0xf5e76000-0xf5e78000
        0xf5e78000-0xf6020000   /lib/i386-linux-gnu/libc-2.19.so
        0xf6020000-0xf6022000   /lib/i386-linux-gnu/libc-2.19.so
        0xf6022000-0xf6023000   /lib/i386-linux-gnu/libc-2.19.so
        0xf6023000-0xf6027000
        0xf6027000-0xf6123000   /usr/lib32/libgfortran.so.3.0.0
        0xf6123000-0xf6124000   /usr/lib32/libgfortran.so.3.0.0
        0xf6124000-0xf6125000   /usr/lib32/libgfortran.so.3.0.0
        0xf6125000-0xf6151000   /usr/lib32/libasan.so.0.0.0
        0xf6151000-0xf6152000   /usr/lib32/libasan.so.0.0.0
        0xf6152000-0xf6153000   /usr/lib32/libasan.so.0.0.0
        0xf6153000-0xf7705000
        0xf7731000-0xf773b000
        0xf773b000-0xf773c000   [vdso]
        0xf773c000-0xf775c000   /lib/i386-linux-gnu/ld-2.19.so
        0xf775c000-0xf775d000   /lib/i386-linux-gnu/ld-2.19.so
        0xf775d000-0xf775e000   /lib/i386-linux-gnu/ld-2.19.so
        0xff80a000-0xff82c000   [stack]
==32656== End of process memory map.

gfortran 版本：

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1)

将大小减小AA1（在我的测试中）可以解决问题。在不同的系统或情况下，限制大小可能不同。

据我所见，公共块的大小远不及 2GB，我预计-m32会出现问题。这是地址清理程序的限制吗？我可以使用任何命令行或运行时技巧来解决该问题吗？

编辑：它可能与公共块无关，但是公共块中的数组即使从未使用过也会被分配。这会导致同样的问题：

      program main
      implicit none
*     real*8, allocatable :: AA(:)
*     !allocate(AA(378272768))
*     allocate(AA(378272769))
      !real*8 AA(50292702)
      real*8 AA(50292705)
      AA(1)=1.0d0
      write(6,*) 'Hello!'
      end program main

请注意，可分配数组的限制几乎是静态数组的 8 倍。

4

1 回答 1

0

这是地址清理程序的限制吗？

事实上，在 32 位 Linux 上，Asan 需要 0x1ffff000-0x37ffffff 的空闲区域作为影子内存（参见其他平台范围的源代码）。这可能与您程序中的大型公共数组相冲突。

我可以使用任何命令行或运行时技巧来解决该问题吗？

不幸的是，该地址在编译器和运行时库中被硬编码（出于性能原因），因此我不确定您是否可以在不更改代码的情况下解决此问题（例如，通过动态分配数组？）。或者您可以坚持使用 64 位版本的代码进行 Asan 测试（那里发生冲突的可能性要低得多）。

作为旁注 - 建议不要将通用数组与 Asan 一起使用（请参阅常见问题解答），因为这将阻止检测其中的缓冲区溢出（不要问）。您可以使用 -fno-common 禁用它们。

于 2016-10-28T16:27:16.173 回答