On Mon, Jun 16, 2008 at 02:07:51PM -0700, Michael E. Corcoran wrote:
> So I realize this is somewhat stupid, and I've actually gotten myself out of
> kmdb to kill my dtrace script but this has happened in the past and I'm
> wondering if there's any better way around it than hitting :c a bunch of
> times.
>
> Say you set a breakpoint() to fire in a common function. This will drop you
> into kmdb where you can do some debugging, you take a look around and say
> great, I got all the data I need now lets continue via :c and wham, right
> back into kmdb at the same breakpoint. So now I'm essentially stuck in kmdb
> since I can't ^C my dtrace script since I'm in kmdb and every :c for
> continuing leads to an almost immediate return to kmdb.
>
> Is there any variable I can set in kmdb which will disable all active dtrace
> probes so that I can get myself out of kmdb? I did a google search and
> couldn't find anything. If there isn't such a variable, I'll file an RFE to
> get one added since I'm sure others might need to use this as well :)
Yes: set dtrace_destructive_disallow to 1. And amazingly enough (and
I don't mean that sarcastically), we actually documented this under the
breakpoint() action:
A mistake with the breakpoint() action may cause it to be called far
more often than intended. This behavior might in turn prevent you from
even terminating the DTrace consumer that is triggering the breakpoint
actions. In this situation, set the kernel integer variable
dtrace_destructive_disallow to 1. This setting will disallow all
destructive actions on the machine. Apply this setting only in this
particular situation.
And we also discussed this in the Advanced DTrace presentation (a.k.a.
"Tips, Tricks & Gotchas") under "stop() gone haywire"...
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks. http://blogs.sun.com/bmc
_______________________________________________
dtrace-discuss mailing list
[email protected]
