Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dynamorio
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,467
    • Issues 1,467
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 44
    • Merge requests 44
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • DynamoRIO
  • dynamorio
  • Issues
  • #2999
Closed
Open
Issue created May 07, 2018 by Derek Bruening@derekbrueningContributor

reduce safe_read faults during app .so loading

Running the linux.thread test in gdb on AArch64 there are many safe_read faults:

#2  0x00000000712f209c in safe_read_ex (base=0xffffb7fa5000, size=64, out_buf=0xffffa4014970, bytes_read=0x0)
    at /home/derek/dr/src/core/unix/os.c:4666
#3  0x00000000712f2138 in safe_read (base=0xffffb7fa5000, size=64, out_buf=0xffffa4014970) at /home/derek/dr/src/core/unix/os.c:4685
#4  0x0000000071327b58 in is_elf_so_header_common (base=0xffffb7fa5000 <error: Cannot access memory at address 0xffffb7fa5000>,
    size=0, memory=true) at /home/derek/dr/src/core/unix/module_elf.c:192
#5  0x0000000071327eb8 in is_elf_so_header (base=0xffffb7fa5000 <error: Cannot access memory at address 0xffffb7fa5000>, size=0)
    at /home/derek/dr/src/core/unix/module_elf.c:248
#6  0x0000000071329c94 in module_is_header (base=0xffffb7fa5000 <error: Cannot access memory at address 0xffffb7fa5000>, size=0)
    at /home/derek/dr/src/core/unix/module_elf.c:750
#7  0x00000000712fed88 in query_memory_ex_from_os (pc=0xffffb7fa5000 <error: Cannot access memory at address 0xffffb7fa5000>,
    info=0xffffa4014a58) at /home/derek/dr/src/core/unix/os.c:9435
#8  0x00000000712fede4 in get_memory_info_from_os (pc=0xffffb7fa5000 <error: Cannot access memory at address 0xffffb7fa5000>,
    base_pc=0xffffa4014ae8, size=0xffffa4014ae0, prot=0xffffa4014adc) at /home/derek/dr/src/core/unix/os.c:9452
#9  0x0000000071325ef0 in memcache_query_memory (pc=0xffffb7fa5000 <error: Cannot access memory at address 0xffffb7fa5000>,
    out_info=0xffffa4014b90) at /home/derek/dr/src/core/unix/memcache.c:374
#10 0x00000000712feba4 in query_memory_ex (pc=0xffffb7fa5000 <error: Cannot access memory at address 0xffffb7fa5000>,
    out_info=0xffffa4014b90) at /home/derek/dr/src/core/unix/os.c:9379
#11 0x00000000712febcc in query_memory_cur_base (pc=0xffffb7fa5000 <error: Cannot access memory at address 0xffffb7fa5000>,
    info=0xffffa4014b90) at /home/derek/dr/src/core/unix/os.c:9386
#12 0x000000007118a424 in app_memory_pre_alloc (dcontext=0xffffa3fe8460,
    base=0xffffb7fa5000 <error: Cannot access memory at address 0xffffb7fa5000>, size=8192, prot=3, hint=false)
    at /home/derek/dr/src/core/vmareas.c:6009
#13 0x00000000712f840c in pre_system_call (dcontext=0xffffa3fe8460) at /home/derek/dr/src/core/unix/os.c:6796

ffffb7fa5000-ffffb7fa7000 r-xp 000a9000 08:03 9833210                    /lib/aarch64-linux-gnu/libm-2.24.so

So it's marked readable but we get SIGBUS b/c the mapped offset is too far (this is an mmap during loading of this .so):

$ ls -l /lib/aarch64-linux-gnu/libm-2.24.so
-rw-r--r-- 1 root root 633656 Jan 14 10:39 /lib/aarch64-linux-gnu/libm-2.24.so
(gdb) p/x 633656
$1 = 0x9ab38

Happens again for the same address a few lines later:

#11 0x000000007118a240 in app_memory_pre_alloc (dcontext=0xffffa3fe8460,
    base=0xffffb7fa5000 <error: Cannot access memory at address 0xffffb7fa5000>, size=8192, prot=3, hint=false)
    at /home/derek/dr/src/core/vmareas.c:6016

Then another pair for libdl, a pair for libc, a 2nd pair for libc.

We could issue a syscall to read the file size and avoid the fault: is that a worthwhile tradeoff on every mmap?

Assignee
Assign to
Time tracking