Server Fault is a question and answer site for system and network administrators. 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

I have somehow managed to mangle my computer so that any time I attempt to use something that uses ptrace to trace another process (eg strace, gdb), I get an immediate segmentation fault.

For example:

# strace /bin/true
execve("/bin/true", ["/bin/true"], [/* 27 vars */]) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

or with gdb:

# gdb /bin/true
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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-redhat-linux-gnu"...
(no debugging symbols found)
(gdb) run
Starting program: /bin/true 

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
You can't do that without a process to debug.

rpm -V comes up clean on strace, gdb, and glibc. I do not have any LD_* variables set, and PATH has nothing special in it.

Update: problem is in the kernel-2.6.18-128 kernel when recompiled with PREEMPT. That kernel emulates ptrace with the utrace infrastructure, and it seems to disagree with preemption. kernel-2.6.18-164 seems to fix it.

share|improve this question

I have this same gdb/strace problem when using on a "Red Hat Enterprise Linux Client 5.5" kernel 2.6.18-194 rebuilt with CONFIG_PREEMPT.


share|improve this answer

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.