Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So recently, I was discussing strace with somebody, and they were asking what would happen if you straced a running process just as it was creating a network socket or something similar. Could this cause the program to crash in unexpected ways?

From what I've read about ptrace, the syscall used by strace, it shouldn't be able to cause anything like that if you're just debugging a thread. The process gets stopped, every time a syscall is called, but it should later resume and be none the wiser. Signals get queued while it's not running, so I assume something similar happens with syscalls/sockets/listen.

Can ptrace used in the context of strace cause any weird process crashes?

share|improve this question
There was a time with ancient kernels that had bugs, where detaching from a process made it "disappear" (getting SIGKILL). This doesn't happen anymore for many years now, but maybe you read about some myths that are still around. Note that with ptrace you have the ability to write to the process memory, but strace doesnt use any ptrace calls for that. – PlasmaHH Aug 4 '14 at 20:44
up vote 6 down vote accepted

No, strace will not cause a program crash -

except in this somewhat theoretical case:

If it has a bug that depends on timing of execution, or runtime memory locations.

It may trigger this kind of "heisenbug" - but extremely rarely, because this kind of bug is rare, and it needs to only trigger under strace or other instrumentation. And when you find a heisenbug, that's often a good thing.

Regarding ptrace() - the syscall - that is just what strace does inside I think, so it's similar. One can just do more than strace can when using ptrace() directly.

Your example would be just this kind of bug:

In the example, strace would change the timing of the steps to create a network connection. If that causes a problem, it was a "problem waiting to happen" - the timing of execution changes constantly. With strace, just a little more. But any other application could have changed the timing more, like starting a program.

share|improve this answer
+1 To clarify WRT sockets, it wouldn't be the actual establishment of a connection that would trigger such a bug. I can't really imagine anyone writing general purpose networking code that was timing critical in this sense, although it's obviously possible. I'm curious as to what you mean by the "runtime memory locations" complication. – goldilocks Aug 4 '14 at 16:43
Oh, true, the network code would be from well tested libs. Regarding the memory, I "just assumed" that the instrumentation with strace somehow changes the memory use or the process, such that null pointers point elsewhere now. Hmmm... if the strace instrumentation happens fully outside the traced process, that may be wrong. ('ltrace' should be in the process, changing library call addresses) – Volker Siegel Aug 4 '14 at 16:51
Exactly the information I was looking for, thanks! So basically, in a well written application, strace/ptrace shouldn't cause issues. Issues that arise while using strace/ptrace may be trigger by other things as well (such as slower computers). I don't think ptrace modifies memory locations, but I'll have to check. – Brandon Wamboldt Aug 4 '14 at 18:18
........... Exact! – Volker Siegel Aug 4 '14 at 18:34
strace only uses eavesdropping features of ptrace. ptrace can also modify the execution of a program, and if you do that, it's very easy to cause the program to crash. – Gilles Aug 4 '14 at 23:05

what would happen if you straced a running process just as it was creating a network socket or something similar.

Stuff like that is done via system calls, meaning the process makes a request of the kernel, and the kernel fulfils it. The kernel also does the magic to make ptrace() work. While this doesn't mean it would be impossible for it to trip over itself (which would be a bug), it seems unlikely as this is explicitly one of its purposes: to coordinate processes on a multitasking system.

share|improve this answer

I find that stracing GUI processes often leads to crashes, even on recent OS (OpenSuse 12.3 at least, I haven't specifically tried on 13.1 as I have pretty much given up on stracing GUI processes).

I can't recall seeing stracing of a non-GUI process lead to crashes on any recent OS.

share|improve this answer
I could see how maybe tracing a GUI program from a terminal running under the same GUI (same X11 display) could trigger a deadlock of some kind, but tracing a GUI program from elsewhere, or tracing it with the trace output redirected to a file shouldn't be able to cause that. – Celada Aug 5 '14 at 1:14
GUI programs often have a lot of race conditions in them due to sloppy coding. This causes crashes. For example, the program might be sending several commands to X and expecting them to all be complete in another thread or signal handler. They get back an unexpected value and don't know what to do. – Zan Lynx Aug 31 '15 at 19:51
For the record, I have the same problem with some GUI programs and I traced it down to NVidia's proprietary CUDA library terminating the process if its (SUID) nvidia-modprobe helper fails. Since strace ptraces it, its suid doesn't work so it fails and the CUDA library terminates the program. – Score_Under Apr 19 at 3:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.