Unable to Run heaptrack (Segfaults Immediately)

Our Neighbors Asahi Linux Ask Asahi
1

Whether installing via dnf or building from source, heaptrack segfaults immediately with every executable I’ve run it with. I’m wondering if anyone has gotten it working, or if its a known 16k page size issue? I don’t see it listed on Broken Software · AsahiLinux/docs Wiki · GitHub, but its behavior does match the description of “instantly segfault”.

I’m not sure how to interpet readelf -l libheaptrack_preload.so, but just in case it’s useful for diagnosing the issue:

Elf file type is DYN (Shared object file)
Entry point 0x0
There are 10 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000002a58 0x0000000000002a58  R      0x10000
  LOAD           0x0000000000010000 0x0000000000010000 0x0000000000010000
                 0x0000000000005598 0x0000000000005598  R E    0x10000
  LOAD           0x0000000000020000 0x0000000000020000 0x0000000000020000
                 0x0000000000001654 0x0000000000001654  R      0x10000
  LOAD           0x000000000002fcd8 0x000000000003fcd8 0x000000000003fcd8
                 0x0000000000000650 0x0000000000000b48  RW     0x10000
  DYNAMIC        0x000000000002fd30 0x000000000003fd30 0x000000000003fd30
                 0x0000000000000220 0x0000000000000220  RW     0x8
  NOTE           0x0000000000000270 0x0000000000000270 0x0000000000000270
                 0x0000000000000024 0x0000000000000024  R      0x4
  TLS            0x000000000002fcd8 0x000000000003fcd8 0x000000000003fcd8
                 0x0000000000000000 0x0000000000000001  R      0x1
  GNU_EH_FRAME   0x0000000000020728 0x0000000000020728 0x0000000000020728
                 0x00000000000001cc 0x00000000000001cc  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
  GNU_RELRO      0x000000000002fcd8 0x000000000003fcd8 0x000000000003fcd8
                 0x0000000000000328 0x0000000000000328  R      0x1

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

This seems to be an issue with libunwind and pointer authentication. Works as expected when adding arm64.nopauth to the kernel command line.

This might be fixed in libunwind 1.8.0. There is a similar report in the libunwind tracker which reports the issue as fixed with 1.8.0: access_mem in aaarch64 coredump · Issue #260 · libunwind/libunwind · GitHub

3

Thank you for looking into this, and the info! I saw libunwind on the fixed list and didn’t look any further into it, but of course fixed is not necessarily a binary state. Building libunwind 1.8.1 and using that to build heaptrack gets me further, with a number of processes successfully able to run under heaptrack. Some processes still segfault, but I haven’t encountered any that segfault immediately anymore (i.e. heaptrack always has some allocations to report, if only a few).

The program I’m trying to run under heaptrack (Halloy) appears to segfault in the early stages of making OpenGL calls. Perhaps related, glxgears also segfaults under heaptrack. I will try learning a bit about the kernel command line so I can attempt adding arm64.nopauth to it (after I understand something of what that will do).

Thanks again.