dtrace discuss - Jun 2008 - "stuck" in kmdb due to dtrace breakpoint()

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 :)


--
This message posted from opensolaris.org

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