Quick Binary Debugging in Linux with Strace System Call Tracer

Orange Pi Development Boards

I’ve recently come across strace, a debugging utility for Linux that “monitor the system calls used by a program and all the signals”. It may not be that useful if you have the source code and can run other debugging tools such as gdb, or simply add printf to your code. But if you don’t have source code of the program, or you are a system administrator who wants to check if the program fails due to file access reasons, for example, this is really a great tool as it may help you find out which file causes problem.

In my case, I was trying OpenGL ES on an ARM platform, and at least part of the code comes in libraries that are only available in binary form.

I got the following error message running es2_info (part of mesa-utils-extra):

UMP: ump_arch_open() failed to open UMP device driver
ERROR: In file: src/base/common/mem/base_common_mem.c  function: initialize_memo
ry_system()   line:1521
Could not open UMP memory system. Shutdown.

Error: eglInitialize() failed

I don’t have the source for src/base/common/mem/base_common_mem.c, and I’ve been advised to use strace to find out if the problem could be file related (missing missing, permission issue…). You may need to install it first (e.g. Ubuntu/Debian):

sudo apt-get install strace

Now time to give it a try:

This will output a debugging information each time a file or a socket is accessed. In this case, strace helped me identify the issue when it showed es2_info could not open /dev/ump device file due to permission issues. Running the program with sudo or changing /dev/ump permission fixed that particular issue.

This is just one example. If you want to know more about the options provided by this tool, simply visit strace manpage.

4 Replies to “Quick Binary Debugging in Linux with Strace System Call Tracer”

  1. Indispensable tool for working out why stuff isn’t working, or if it is working, what it is doing. Been using it since i started using linux – a good 15+ years ago, and truss before that (sunos/solaris)

    A couple of extremely useful options for copying with it’s voluminous output & tracing more complex stuff:

    Only trace ‘open’ calls:
    -e open
    Log to a file:
    -o dump.txt
    Follow forks/child processes:

  2. I want to compile mali400 drivers without X support. Do you have any idea how can I do that? Do I need trusted source code from ARM to make that. I saw some sources on ARM sites but I don’t know if it is enaught.

Comments are closed.