记录bug

-bash: ./app: no such file or directory

Bug产生背景：项目里用g++编译产生*.o，然后再用动态链接得到可执行文件app，执行时发现无法运行，报错信息非常奇怪，是-bash: ./app: no such file or directory。看到这个报错我的第一反应当然是检查文件是否存在，ls指令告诉我文件的确存在。

# ls -lh | grep app
-rwxr-xr-x 1 root root 115K Aug 25 17:34 app

遇到没有见过的bug，首先要做的当然是搜索有没有类似的问题。用关键词"bash", "no such file or directory"的确搜索到了很多post，提示有可能是文件的位数和系统位数不一致，比如32的文件尝试在64位系统上执行，就会产生这个错误。file指令告诉我文件是64位的，然后uname指令又告诉我系统也是64位的。因此这个原因被排除了。

# file app
app: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, 
for GNU/Linux 2.6.32, BuildID[sha1]=01185822dd63c4dd6da6c6673ae7bdc36f8cac43, not stripped

# uname -a
Linux vca_node_00 4.14.20-1.2.3.26.vca #1 SMP Wed Nov 28 17:11:04 CET 2018 x86_64 x86_64 x86_64 GNU/Linux

更进一步的搜索结果暗示bug可能是缺失的系统库引起的，用ldd命令检查发现系统库一切正常。

# ldd app
        linux-vdso.so.1 =>  (0x00007ffe1ba94000)
        libsgx_urts.so => /usr/lib/x86_64-linux-gnu/libsgx_urts.so (0x00007f01fd02b000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f01fce0e000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f01fca8c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f01fc6c2000)
        libsgx_enclave_common.so.1 => /usr/lib/x86_64-linux-gnu/libsgx_enclave_common.so.1 (0x00007f01fc4b2000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f01fc2ae000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f01fc098000)
        /lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f01fd26e000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f01fbd8f000)
        libsgx_uae_service.so => /usr/lib/x86_64-linux-gnu/libsgx_uae_service.so (0x00007f01fbb10000)
        libprotobuf.so.9 => /usr/lib/x86_64-linux-gnu/libprotobuf.so.9 (0x00007f01fb7f2000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f01fb5d8000)

感觉debug陷入了走投无路的阶段了。直接解析源码，发现program sections一切正常。

# readelf -l app

Elf file type is EXEC (Executable file)
Entry point 0x4017d0
There are 8 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001c0 0x00000000000001c0  R E    8
  INTERP         0x0000000000000200 0x0000000000400200 0x0000000000400200
                 0x000000000000000f 0x000000000000000f  R      1
      [Requesting program interpreter: /lib/ld64.so.1]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x000000000000a3c8 0x000000000000a3c8  R E    200000
  LOAD           0x000000000000ac80 0x000000000060ac80 0x000000000060ac80
                 0x0000000000000718 0x0000000000000998  RW     200000
  DYNAMIC        0x000000000000add8 0x000000000060add8 0x000000000060add8
                 0x0000000000000200 0x0000000000000200  RW     8
  NOTE           0x0000000000000210 0x0000000000400210 0x0000000000400210
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x000000000000ac80 0x000000000060ac80 0x000000000060ac80
                 0x0000000000000380 0x0000000000000380  R      1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame .gcc_except_table 
   03     .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss 
   04     .dynamic 
   05     .note.ABI-tag .note.gnu.build-id 
   06     
   07     .init_array .fini_array .jcr .data.rel.ro .dynamic .got

但program headers中有一行引人注意：[Requesting program interpreter: /lib/ld64.so.1]。结合关键词ld64.so.1，新的搜索结果显示尽管ldd告诉我们系统知道了这个库的位置，但在/lib64文件夹下的库在程序装载时无法使用。这个库是一个关键的动态链接库，失去这个库程序必然无法运行。

解决方法是建立软链接/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2，或者直接把库从/lib64中拷贝到/lib中来。完成库的修复后，再次执行app，结果一切正常。

尽管问题解决了，但bug的内在机理，bug的生成原因目前尚不知晓。推测与编译链接过程中的某些不当操作有关。