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.
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
Responsible Changed From-To: freebsd-bugs->markj I'll take this.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped