7

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?

  • 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
10

No, strace should not cause a program crash -

Except in this somewhat unusual 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.

| 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
  • 1
    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 'SO- stop being evil' Aug 4 '14 at 23:05
3

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.

| improve this answer | |
1

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.

| 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
  • 2
    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 '16 at 3:41
0

Yes. It's rare, and I don't have a good idea why, but it definitely happens. Recently I had this happen to me tracing a long-running "swapoff" command and there was no network access nor anything else that looked like it would/should cause a problem. Nonetheless, shortly after strace was attached the process exited.

>strace -p 73358
strace: Process 73358 attached
getuid()                                = 0
geteuid()                               = 0
getgid()                                = 0
getegid()                               = 0
prctl(PR_GET_DUMPABLE)                  = 1
stat("/etc/fstab", {st_mode=S_IFREG|0644, st_size=2168, ...}) = 0
open("/etc/fstab", O_RDONLY|O_CLOEXEC)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2168, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f24e5cd8000
read(3, "\n#\n# /etc/fstab\n# Created by ana"..., 4096) = 2168
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x7f24e5cd8000, 4096)            = 0
close(1)                                = 0
close(2)                                = 0
exit_group(-1)                          = ?
+++ exited with 255 +++

It looks like the process decided to voluntarily exit, but considering that it had run for several hours before the strace was started, I doubt that this exit was coincidence.

So yes, strace can sometimes cause the process to abort, but it's rare enough that the benefits of getting good info can outweigh that risk.

Another option on linux would be to check /proc/<PID>/stack to see where the process is currently blocked. This is safer, but provides less dynamic information.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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