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
  • #2100
Closed
Open
Issue created Dec 09, 2016 by Administrator@rootContributor

tools/libdynamorio.so-gdb.py causes "RuntimeError: Cannot access memory at address 0x712fd867"

Created by: thorstent

I'm running DynamoRIO on a fresh Ubuntu 16.10 64bit VM in VirtualBox (Host is Windows).

I am using DynamoRIO 6.2 binary release. But the problem persists with the latest nightly 6.2.17144-0x12112de7

My ~/.gdbinit file constists of these two lines:

add-auto-load-safe-path /home/ttarrach/Downloads/DynamoRIO-Linux-6.2.0-2/lib64/debug/libdynamorio.so.6.2-gdb.py
add-auto-load-safe-path /home/ttarrach/Downloads/DynamoRIO-Linux-6.2.17144-0x12112de/lib64/debug/libdynamorio.so.6.2-gdb.py

The minimal steps to reproduce this problem are:

  1. start GDB: ~/Downloads/DynamoRIO-Linux-6.2.0-2$ gdb --args bin64/drrun -debug -- ls
  2. type run into the GDB command prompt

Here is the complete output:

GNU gdb (Ubuntu 7.11.90.20161005-0ubuntu1) 7.11.90.20161005-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from bin64/drrun...Reading symbols from /home/ttarrach/Downloads/DynamoRIO-Linux-6.2.0-2/bin64/drrun.debug...done.
done.
(gdb) run
Starting program: /home/ttarrach/Downloads/DynamoRIO-Linux-6.2.0-2/bin64/drrun -debug -- ls
process 2728 is executing new program: /home/ttarrach/Downloads/DynamoRIO-Linux-6.2.0-2/lib64/debug/libdynamorio.so.6.2
Loading gdb scripts for debugging DynamoRIO...
Traceback (most recent call last):
  File "/home/ttarrach/Downloads/DynamoRIO-Linux-6.2.0-2/lib64/debug/libdynamorio.so.6.2-gdb.py", line 185, in <module>
    PrivloadBP()
  File "/home/ttarrach/Downloads/DynamoRIO-Linux-6.2.0-2/lib64/debug/libdynamorio.so.6.2-gdb.py", line 151, in __init__
    internal=not self.DEBUG)
RuntimeError: Cannot access memory at address 0x712fd867
<Starting application /bin/ls (2728)>
<Paste into GDB to debug DynamoRIO clients:
set confirm off
add-symbol-file '/home/ttarrach/Downloads/DynamoRIO-Linux-6.2.0-2/lib64/debug/libdynamorio.so' 0x000000007102d808
>
<Initial options = -no_dynamic_options -code_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -early_inject -emulate_brk -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct >

I would expect the python script to run and not throw a memory exception. The same problems I observed in my Debian Jessie VM.

Assignee
Assign to
Time tracking