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
  • #3074
Closed
Open
Issue created Jun 28, 2018 by Derek Bruening@derekbrueningContributor

drcachesim: improve analyzer tool error messages

An error in process_memref in the middle of trace analysis has no way to return an error code or string to the user: we just get a generic "failed to run analyzer". Worse, it finishes processing the trace before reporting this.

Plus, some tools do not provide error messages for initialization errors. Here's opcode_mix with a bad path in modules.log (a not-uncommon error):

$ bin64/drrun -t drcachesim -simulator_type opcode_mix -indir drmemtrace.runstats.133585.7612.dir/ -module_file drmemtrace.runstats.133585.7612.dir/raw/modules.log 
Failed to create analysis tool
ERROR: failed to initialize analyzer

This issue covers several proposed changes:

  • Have the analyzer abort on any error during processing. The original logic was to continue in case one tool was successful when running multiple tools, but IMHO this is a rarer occurrence and is outweighed by the benefit of finding out about an error early.

  • Add a mechanism to return an error string from process_memref and print_results. I already tried changing process_memref to return std::string instead of a bool but the performance hit is actually noticeable on a quick benchmark:

$ rm -rf drmemtrace.*.dir; rm -f /tmp/x.gz; \cp -f bin64/drinject /tmp/x; bin64/drrun -t drcachesim -offline -- gzip /tmp/x; /usr/bin/time bin64/drrun -t drcachesim -simulator_type basic_counts -indir drmemtrace.*.dir; gzip drmemtrace.*.dir/*.trace

$ /usr/bin/time bin64/drrun -t drcachesim -simulator_type basic_counts -infile ../build_x64_dbg_tests/drmemtrace.*.dir/drmemtrace.trace.gz
9.86user 0.01system 0:09.87elapsed 99%CPU (0avgtext+0avgdata 4632maxresident)k

$ /usr/bin/time ~/Downloads/DynamoRIO-x86_64-Linux-7.0.17704-0/bin64/drrun -t drcachesim -simulator_type basic_counts -infile ../build_x64_dbg_tests/drmemtrace.*.dir/drmemtrace.trace.gz
8.66user 0.01system 0:08.68elapsed 99%CPU (0avgtext+0avgdata 4236maxresident)k

I'm thinking of having a separate error string field that can be queried when the bool return value is false.

  • Ensure all tools report error messages on init-time errors. This could use the stderr-printing mechanism used today but it would be cleaner to use the string field mentioned above and keep the tools modular.
Assignee
Assign to
Time tracking