kern/187912: Getting Stack Traces of Xorg with DTrace Causes Hang

[John D. Hendrickson and Sara Darnell]

The following reply was made to PR kern/187912; it has been noted by GNATS.

From: "John D. Hendrickson and Sara Darnell" <johnandsara2 at cox.net>
To: Nick Zivkovic <zivkovic.nick at gmail.com>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: kern/187912: Getting Stack Traces of Xorg with DTrace Causes
 Hang
Date: Tue, 25 Mar 2014 17:44:34 -0400

 Nick Zivkovic wrote:
 >> Number:         187912
 >> Category:       kern
 >> Synopsis:       Getting Stack Traces of Xorg with DTrace Causes Hang
 >> Confidential:   no
 >> Severity:       non-critical
 >> Priority:       low
 >> Responsible:    freebsd-bugs
 >> State:          open
 >> Quarter:        
 >> Keywords:       
 >> Date-Required:
 >> Class:          sw-bug
 >> Submitter-Id:   current-users
 >> Arrival-Date:   Mon Mar 24 23:50:00 UTC 2014
 >> Closed-Date:
 >> Last-Modified:
 >> Originator:     Nick Zivkovic
 >> Release:        10.0 (r260789)
 >> Organization:
 > N/A
 >> Environment:
 > FreeBSD Stalingrad 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014     root at snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
 >> Description:
 > When executing the following DTrace script:
 > 
 > sudo dtrace -n 'syscall:::entry /execname == "Xorg"/ {@[ustack()] = count();}'
 > 
 > and pressing ^C, the Xserver freezes. The machine (a laptop) is unresponsive.
 > 
 > So I ssh'd into the laptop (from a different laptop), and did:
 > 
 > pgrep dtrace
 > 
 > Sure enough the dtrace exec was still alive, but not doing anything (that I can tell).
 > 
 > Firefox still did IO and stuff, but Xorg didn't have _any_ activity (according to top).
 > 
 > So I did a `kill -9 $(my-dtrace-pid)`
 > 
 > This caused Xorg to restart.
 > 
 > Bottom line: running that simple (and common) DTrace script froze Xorg. I don't mean to be inflammatory but, this should _never_ happen, especially not in production --- which means that the FreeBSD DTrace implementation is violating DTrace's original design constraints. This is a critical error, and shows that FreeBSD's DTrace may not be suitable for production use, yet.
 > 
 > So far I've only been able to replicate this on Xorg.
 > 
 > It may be of importance that I did `make buildworld` and `make installworld` with the following options:
 > 
 > CFLAGS+=-fno-omit-frame-pointer
 > STRIP=
 > WITH_CTF=1
 > 
 > In other words I made all of my installed packages dtrace-friendly.
 > 
 > 
 >> How-To-Repeat:
 > When running Xorg (not stripped, no frame-pointer optimization, and with CTF) run:
 > 
 > sudo dtrace -n 'syscall:::entry /execname == "Xorg"/ {@[ustack] = count();}'
 > 
 > resize windows, click around, etc.
 > 
 > go back to terminal and hit ^C.
 >> Fix:
 > 
 > 
 >> Release-Note:
 >> Audit-Trail:
 >> Unformatted:
 > _______________________________________________
 > freebsd-bugs at freebsd.org mailing list
 > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
 > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe at freebsd.org"
 > 
 
 
 ----------------------------------------
 now that's a can of worms !
 
 i'm poor at BSD, not a maintainer i use other mostly, but let me make 
 some suggestions:
 
 DTrace, also known as Dynamic Tracing, was developed by Sun™ as a tool 
 for locating performance bottlenecks in production and pre-production 
 systems. It is not, in any way, a debugging tool, but a tool for real 
 time system analysis to locate performance and other issues.
 
 
 #0 this tells me it is meant for regression testing / engineering not 
 normal users
 
 #1 if it's for Sun they used a nice BUS, not same - maybe on their bus 
 there was no bus error
 
 #2 did you try running X.org using frame buffer driver ?
 
 #3 i'm sure you know signaling buses and interrupts can be touchy
 
 #4 keeping video card in right mode / failing to be in right state can 
 be touchy
 
 i'm thinking DTrace uses debug abilities of hardware, not just kernel 
 commands, to peek.  that's important because if one emulated it would 
 one do so in parallel or in spinlock ?
 
 what was #2?  well if X runs as root for access to video card.  if 
 there are permission problems or any problem or if video card doesn't 
 respond it takes system down.  like breaking a vacuum tube you might 
 say, which runnign as "normal user" protects against.  but ah there 
 are ways to fool X to do the wrong thing after it logs in as user 
 because !due to crap quality video cards! it still must be root in 
 some cases
 
 next we have to drag the cat in and ask which hw your running :)
 
 good luck ,  John