dtrace discuss - Jun 2008 - Apple fixes DTrace

I''m pleased to pass along news that the Mac OS X DTrace port has been  
updated
in 10.5.3 to fix the issue that caused timer based probes not to fire  
in the
presence of certain untraceable applications.

   http://blogs.sun.com/ahl/entry/apple_updates_dtrace

A big thank you to the folks at Apple for addressing the problem.

Adam

--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

On Jun 7, 2008, at 3:38 PM, Adam Leventhal wrote:
> I''m pleased to pass along news that the Mac OS X DTrace port has
been
> updated
> in 10.5.3 to fix the issue that caused timer based probes not to fire
> in the
> presence of certain untraceable applications.
Thanks for the mention!

In
>
>   http://blogs.sun.com/ahl/entry/apple_updates_dtrace
you write:
>> "For the Apple folks: I''d argue that revealing the name
of
>> otherwise untraceable processes is no more transparent than what  
>> Activity Monitor provides ? could I have that please?"

Let''s see what we can do. To cover this issue I''ve filed:
<rdar://problem/5996285> DTrace: restore execname and pid lossage when  
P_LNOATTACH is asserted

and:
>> "Also, I''m not sure if this has always been true, but the
ustack()
>> action doesn''t seem to work from the profile action"

We encountered this some time ago. It''s a very deep constraint on our  
ability to do copyin() on the interrupt stack. I''d like to fix this,  
but it will be challenging on a number of fronts.
<rdar://problem/5369033> DTrace: ustack() action fails under profile  
and tick probes

SCP
--
Steve Peters
scp at mac.com

On Mon, Jun 09, 2008 at 05:16:37PM -0700, Steve Peters
wrote:
>>> "For the Apple folks: I''d argue that revealing the
name of otherwise
>>> untraceable processes is no more transparent than what Activity
Monitor
>>> provides ? could I have that please?"
>
> Let''s see what we can do. To cover this issue I''ve filed:
> <rdar://problem/5996285> DTrace: restore execname and pid lossage
when
> P_LNOATTACH is asserted
Cool. Would it be possible to expose all kernel state? There are very few
data specific to a thread that couldn''t be dredged up by some other
thread
so nothing''s really being hidden.
> We encountered this some time ago. It''s a very deep constraint on
our
> ability to do copyin() on the interrupt stack. I''d like to fix
this, but it
> will be challenging on a number of fronts.
> <rdar://problem/5369033> DTrace: ustack() action fails under profile
and
> tick probes
That sounds awful :-)

Aside from inflamatory blog posts, is there some mechanism members of the
DTrace community can use to file bugs that will get on your radar? And I
hope I won''t get laughed off the email list by asking if
there''s any sort
of visibility into what bug fixes are being worked on, and in what release
they might be available.

Adam

-- 
Adam Leventhal, Fishworks                     http://blogs.sun.com/ahl