Segfault after patching with 0.10 on i386 and ppc64le

[cmatsuoka]

During the development cycle of Snapcraft 3.4 we ran into a scenario where certain binaries started to fail after patched with patchelf 0.10 in certain architectures like i386 and ppc64le. In this situation patchelf 0.9 worked correctly, and a bisection told us the offending commit is c4deb5e. However, it seems to be a bad interaction between this patch and one or more of the preceding commits, since just applying c4deb5e over 0.9 (along with a couple of other cherry-picked patches) won't cause patchelf to fail.

At the moment the only known failing binary is the apt-get http helper. Here is the diff between the good and bad headers and section to segment mappings:

--- header-good 2019-04-10 23:37:48.407795602 +0000
+++ header-bad  2019-04-10 23:37:41.543753845 +0000
@@ -1,31 +1,31 @@
 
 Elf file type is DYN (Shared object file)
 Entry point 0x3dea
-There are 10 program headers, starting at offset 90112
+There are 10 program headers, starting at offset 52
 
 Program Headers:
   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
-  PHDR           0x016000 0x00016000 0x00016000 0x00140 0x00140 R E 0x4
+  PHDR           0x000034 0x00000034 0x00000034 0x00140 0x00140 R E 0x4
   LOAD           0x000000 0x00000000 0x00000000 0x12f5e 0x12f5e R E 0x1000
   GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
   NOTE           0x000168 0x00000168 0x00000168 0x00044 0x00044 R   0x4
   GNU_EH_FRAME   0x0109e4 0x000109e4 0x000109e4 0x002c4 0x002c4 R   0x4
   LOAD           0x013b18 0x00014b18 0x00014b18 0x004f8 0x00588 RW  0x1000
   GNU_RELRO      0x013b18 0x00014b18 0x00014b18 0x004e8 0x004e8 R   0x1
-  LOAD           0x016000 0x00016000 0x00016000 0x01d7c 0x01d7c RW  0x1000
-  DYNAMIC        0x016140 0x00016140 0x00016140 0x00100 0x00100 RW  0x4
-  INTERP         0x017d54 0x00017d54 0x00017d54 0x00025 0x00025 R   0x1
+  DYNAMIC        0x015000 0x00015000 0x00015000 0x00100 0x00100 RW  0x4
+  LOAD           0x015000 0x00015000 0x00015000 0x01c5c 0x01c5c RW  0x1000
+  INTERP         0x016c14 0x00016c14 0x00016c14 0x00025 0x00025 R   0x1
       [Requesting program interpreter: /snap/core/current/lib/ld-linux.so.2]
 
  Section to Segment mapping:
   Segment Sections...
    00     
-   01     .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .gnu.version .gnu.version_r .rel.dyn .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table 
+   01     .note.gnu.build-id .gnu.hash .dynsym .gnu.version .gnu.version_r .rel.dyn .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table 
    02     
-   03     .note.ABI-tag .note.gnu.build-id 
+   03     .note.gnu.build-id 
    04     .eh_frame_hdr 
    05     .init_array .fini_array .jcr .data.rel.ro .got .data .bss 
    06     .init_array .fini_array .jcr .data.rel.ro .got 
-   07     .dynamic .dynstr .interp 
-   08     .dynamic 
+   07     .bss .dynamic 
+   08     .bss .dynamic .dynstr .interp .note.ABI-tag 
    09     .interp 

[cmatsuoka]

The problem was indeed caused by c4deb5e but I confirm that commit 1cc234f in Ed Bartosh's patchelf tree (which was also part of our small collection of cherry-picked patches) fixes the problem in 0.10. It's in PR #127.

[domenkozar]

Would be great to see if #202 also fixes this one or is #127 still needed.

[domenkozar]

Both are merged now.