Re: Userland dtrace broken?
On 09/13/12 18:04, Chris Nehren wrote: Relevant to my interests, too. I've followed the instructions on the wiki / in the handbook (on 9.0/9.1-PRE) and only receive error messages. Is DTrace supposed to be working properly on 9.x, or is it still experimental? From my experience, as long as you avoid using the pid provider, and don't bother trying to get fbt:::return arguments, then it works reliably. I haven't tried userland static probes though. Tracing userland works *occasionally* (I find maybe ~20% of the time when it's the first command run on a machine with 1m uptime), but you're more likely to get strange results, or just a panic. -- The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Userland dtrace broken?
On Wed, Aug 29, 2012 at 14:01:15 +0100 , Matt Burke wrote: Following http://wiki.freebsd.org/DTrace/userland on 9.1-RC1, the example fails to work as demonstrated: # dtrace -s pid.d -c test dtrace: script 'pid.d' matched 2 probes CPU IDFUNCTION:NAME 1 59284 main:entry dtrace: pid 25479 exited with status 1 # Also, I get hangs when trying to do pretty much anything with the pid:::entry # dtrace -n 'pid$target::malloc:entry' -c 'echo x' dtrace: description 'pid$target::malloc:entry' matched 2 probes xCPU IDFUNCTION:NAME 1 59311 malloc:entry load: 0.43 cmd: dtrace 63737 [running] 8.93r 1.60u 4.19s 35% 25072k load: 0.88 cmd: echo 63738 [running] 45.10r 2.27u 18.75s 47% 1452k load: 1.19 cmd: dtrace 63737 [running] 70.32r 12.14u 33.27s 64% 25072k # procstat -k 63737 63738 PIDTID COMM TDNAME KSTACK 63737 101505 dtrace -mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep do_wait __umtx_op_wait_uint_private amd64_syscall Xfast_syscall 63737 111024 dtrace -running 63738 101657 echo -mi_switch thread_suspend_switch ptracestop cursig ast doreti_ast I have previously tried using dtrace on 9.0R, but it was insta-panic. Is there anything I may have missed here? make.conf: STRIP= CFLAGS+=-fno-omit-frame-pointer WITH_CTF=1 kernel config: include GENERIC ident DTRACE makeoptions DEBUG=-g makeoptions WITH_CTF=1 options KDTRACE_FRAME options KDTRACE_HOOKS options DDB_CTF options DDB Relevant to my interests, too. I've followed the instructions on the wiki / in the handbook (on 9.0/9.1-PRE) and only receive error messages. Is DTrace supposed to be working properly on 9.x, or is it still experimental? It's nice to say that FreeBSD nominally supports DTrace, but if it doesn't actually work then it needs to be labelled as such. I am fine with it being experimental if that's the case, but saying so would help manage expectations a lot better. -- Thanks and best regards, Chris Nehren pgpRAM1lTvPSz.pgp Description: PGP signature
