On Oct 26, 2007, at 3:27 PM, Adam Leventhal wrote:
> On Fri, Oct 26, 2007 at 04:51:44PM -0500, Robert Lor wrote:
>> We're not using 'dtrace -h' now, so I'm not following how the
>> 'dtrace -G..."
>> step can be removed. Maybe I'm missing something!
>
> Ah. I thought that Apple might have added
On Oct 27, 2007, at 9:30 AM, Adam Leventhal wrote:
> As has been previously stated, it's pretty great to see the DTrace
> port to
> Mac OS X... if for no other reason than it affords me the
> opportunity to
> _submit_ bugs rather than being responsible for fixing them ;-)
>
> If I use a uintp
On Oct 29, 2007, at 4:48 PM, Adam Leventhal wrote:
> On Mon, Oct 29, 2007 at 01:43:19PM -0700, James McIlree wrote:
>> OS X doesn't support the older DTRACE_PROBE style macros, only
>> the newer (and much safer!) typechecked generated header files.
>
> That makes s
On Nov 2, 2007, at 1:36 PM, Robert Lor wrote:
> James,
>
> From: James McIlree <[EMAIL PROTECTED]>
>>
>> OS X doesn't support the older DTRACE_PROBE style macros, only
>> the newer (and much safer!) typechecked generated header files.
>>
>
&g
Does anyone know why these scripts behave differently?
It looks to me like the thread local variable is being treated as
un-initialized, or a pointer without backing store.
Is this intentional?
James M
# cat global.d
struct foo { int a; };
struct foo ttest;
BEG
On Nov 11, 2007, at 9:43 PM, Adam Leventhal wrote:
> On Sat, Nov 10, 2007 at 08:58:12AM -0700, Rich Morin wrote:
>> At WWDC, some Apple folks discussed turning on DTrace early
>> in the boot process. I gather that this uses anonymous
>> tracing, but I'm not at all sure where they started up the
Andreas,
You may be hitting a case where dtrace thinks it cannot
safely instrument the return points in that function. Try running
this (where XYZ is the pid of your target process)
dtrace -xdebug -l -n 'pidXYZ::sge_mirror_process_events:return'
If dtrace prints a warning about f
On Nov 20, 2007, at 7:55 PM, Rich Morin wrote:
> At 15:36 +0100 11/20/07, Joerg Schilling wrote:
>> If you convert to ## and if Dtrace on Solaris still calls
>> /lib/cpp, it will no longer work on Solaris.
>>
>> Check the __CONCAT__ macro in /usr/include/sys/*.h
>
> Well, "grep __CONCAT__ /usr/in
On Nov 20, 2007, at 7:55 PM, Rich Morin wrote:
> At 15:36 +0100 11/20/07, Joerg Schilling wrote:
>> If you convert to ## and if Dtrace on Solaris still calls
>> /lib/cpp, it will no longer work on Solaris.
>>
>> Check the __CONCAT__ macro in /usr/include/sys/*.h
>
> Well, "grep __CONCAT__ /usr/in
On Nov 19, 2007, at 8:48 PM, Rich Morin wrote:
> When I run "cpp -C", the evil spaces do not appear. However,
> there's no telling what options dtrace is sending to cpp. I
> looked at the dtrace man page on Leopard, and it says:
>
> -C Run the C preprocessor cpp over D programs before compili
On Nov 25, 2007, at 4:53 PM, Rich Morin wrote:
> Some of the proc probes listed in the SDTG
>
> proc:::fault
> proc:::start
> proc:::signal-clear
>
> are getting nastygrams under Mac OS X 10.5 (matches no probes),
> so I used the command "dtrace -l | grep proc" (and some editing)
> to produce:
On Nov 26, 2007, at 8:38 AM, Adam Leventhal wrote:
>> We're having some internal "discussions" on the correct way to
>> handle/implement these probes. They're MIA now, in the worst case
>> scenario we'll add them back as non-functional stubs so scripts
>> compile
>> without errors. I hope
On Nov 26, 2007, at 11:09 AM, Bryan Cantrill wrote:
>
> Zone ID may not be a good example of what you're talking about -- for
> pr_zoneid, I think you should act as a Solaris machine would if it had
> no installed zones. (That is, always return 0 for pr_zoneid to
> denote the
> global zone.) T
--- Forwarded message --
> Date: Wed, 14 Nov 2007 19:52:51 +0100 (MET)
> From: [EMAIL PROTECTED]
> To: dtrace-discuss@opensolaris.org
> Cc: Chris Dagdigian <[EMAIL PROTECTED]>, James McIlree <[EMAIL PROTECTED]
> >
> Subject: Re: [dtrace-discuss] [GE users] A
>
> We have an open question to Apple on this issue. James agreed that it
> was odd, and is following up with the responsible engineer. James,
> perhaps you could send your findings to dtrace-discuss?
I've talked with the folks involved, I think this was just an accident.
It doe
>
> We have an open question to Apple on this issue. James agreed that it
> was odd, and is following up with the responsible engineer. James,
> perhaps you could send your findings to dtrace-discuss?
>
> - Bryan
Just to verify...
These are the recommended signatures for p
On Dec 13, 2007, at 12:41 PM, John Birrell wrote:
> Has anyone seen where Apple has posted their DTrace port to Leopard?
>
> I expected to find it here:
> http://www.opensource.apple.com/darwinsource/10.5/
> but the link just goes to a generic "not available" page.
>
> I have sent mail to [EM
On Dec 14, 2007, at 3:54 PM, James McIlree wrote:
> We're actively pushing, kicking and screaming to get the source out
> ASAP.
>
> I'll send an update when it makes it to the web. Apologies for the
> delay, sometimes
> it takes a while to dot all t
On Dec 18, 2007, at 12:43 AM, Jon Haslam wrote:
> Hi James,
>
>> I just got word, the OS X dtrace source has been posted:
>>
>> http://www.opensource.apple.com/darwinsource/10.5/dtrace-48/
>>
>> In the interest of full disclosure, the sources as they sit will not
>> build correctly
Tiller,
In this case, its because dtrace believes there is a jump table:
ghopper:/# dtrace -xdebug -l -n 'pid$target::memcpy:' -c /usr/bin/true
[ ... ]
libdtrace DEBUG: grabbed pid 76537 (cached)
libdtrace DEBUG: creating probe pid76537:libSystem.B.dylib:memcpy:*
libdtrace DEBUG:
On Jan 30, 2008, at 10:08 AM, Adam Leventhal wrote:
> On Tue, Jan 29, 2008 at 10:47:57PM -0500, Angelo Rajadurai wrote:
>> It would be wonderful to have dtrace -l -n *1234::: show all the pid
>> probes.
>
> I should have been clearer. Today, that will show existing pid probes.
> After the fix it
On Jan 30, 2008, at 11:19 AM, Adam Leventhal wrote:
> On Wed, Jan 30, 2008 at 11:05:04AM -0800, James McIlree wrote:
>> We've had several requests for this feature.
>>
>> An interesting question we've debated is should such
>> a feature include
Vattini,
The tcpsnoop script needs some porting work before it will do the
right thing on
OS X. If you need a short term workaround, you can see quite a bit
using tcpdump.
We do plan to get all of the wonderful DTTK scripts working
eventually, but I can't
make any promises about when
On Feb 4, 2008, at 2:29 PM, Tiller Beauchamp wrote:
> I have had trouble tracing applications in Leopard that have spaces
> in the
> name.
>
> $ sudo dtrace -n 'pid$target:a.out::entry' -c './Address\ Book'
> dtrace: invalid probe specifier pid$target:a.out::entry: probe
> description
> pid25
On Mar 7, 2008, at 10:17 AM, G Bulmer wrote:
> Help
>
> I have been working on inserting SDT's into Erlang.
> I am having several problems. I have just moved environments (see
> Background) and this may be contributing to the problems.
>
> I'm on Mac OS X 10.5.2, and I get a link time error fro
On Mar 11, 2008, at 4:00 PM, Paul Nasrat wrote:
> I was looking at mod_trace
> (http://prefetch.net/projects/apache_modtrace/index.html
> ) and playing with getting it to compile on OS X.
>
> When building for x86_64 with -arch x86_64 we get bad instructions
> generated:
>
> gcc -o foo -arch
On Mar 12, 2008, at 12:27 AM, Paul Nasrat wrote:
>
> On 11 Mar 2008, at 23:19, James McIlree wrote:
>>
>>
>>> I was looking at mod_trace
>>> (http://prefetch.net/projects/apache_modtrace/index.html
>>> ) and playing with getting it to compile o
On Mar 22, 2008, at 7:33 AM, Kathleen wrote:
> I am currently working with the ZFS port to OS X which is a kext. I
> had heard that you cannot use DTrace on kexts in OS X at the
> moment. Does anyone know why?
The dog ate that code.
Kexts are SO nineties, we think they're g
On Mar 26, 2008, at 9:58 AM, Sudheer wrote:
> Hi,
> I am using DTrace to analyze Mozilla Firefox. I want to print
> the ustack, args[2] for the following two C++ methods.
>
> nsComponentManagerImpl::CreateInstance(const nsCID &aClass,
>
On Mar 26, 2008, at 1:59 PM, Sudheer wrote:
>
>> argX is "mostly" the same as args[X]. The difference
>> e is that argX is
>> the raw
>> ABI, not a typed argument. So you'll run into things
>> like "On this
>> arch, a 64 bit value
>> is passed in two argument slots." If you don't get
>> the answer
On Apr 21, 2008, at 11:00 AM, Adam Leventhal wrote:
>
>
> Either we need to use some temporary, probe-local variable (one that
> can't
> conflict with a user-defined variable), or we need to perform some
> element of
> optimization to the generated DIF.
>
> I've filed this bug:
>
> 6691541 cu
On Apr 21, 2008, at 1:04 PM, Adam Leventhal wrote:
> On Mon, Apr 21, 2008 at 11:45:25AM -0700, James McIlree wrote:
>>> Either we need to use some temporary, probe-local variable (one
>>> that can't
>>> conflict with a user-defined variable), or we need t
On May 7, 2008, at 6:19 AM, Chris Dumoulin wrote:
> Could this error be related to using GNU ld? This thread:
> http://mail.opensolaris.org/pipermail/dtrace-discuss/2006-March/001199.html
> indicates that DTrace USDT might not work with GNU ld, but that
> posting was over two years ago.
>
> Shou
On Jun 11, 2008, at 1:22 PM, Brendan Gregg - Sun Microsystems wrote:
> G'Day,
>
> This issue was news to me, and may be useful for readers of this list.
>
> In brief:
>
> USDT providers on MacOS X that are built with the -dead_strip linker
> option
> have their probes fired twice by mistake. T
On Jun 17, 2008, at 4:47 AM, Kay Röpke wrote:
>
> Now the problems start: I meant to pass in high-level information into
> the probe, because that will maximize the flexibility of writing
> scripts.
> But now writing a D script that makes use of con means either
> - including the structs and enum
On Jun 25, 2008, at 12:45 PM, Robert Lor wrote:
> James McIlree wrote:
>> On Oct 27, 2007, at 9:30 AM, Adam Leventhal wrote:
>>
>>
>>> As has been previously stated, it's pretty great to see the
>>> DTrace port to
>>> Mac
On Jul 1, 2008, at 9:16 PM, Domas Mituzas wrote:
> Hello,
>
>> I can't really comment on when it will be fixed, but in general I
>> would hazard a guess
>> that this doesn't rise to the level of impact that would allow it to
>> be included with a 10.x.xrelease. I've been wrong before, YMMV, not
On Jul 1, 2008, at 10:57 PM, Domas Mituzas wrote:
> Helloes,
>
>> String is a 'D' type, not a C type. Long story short, you want to
>> use char*, not string.
>
> Oki, thats what I thought - though now I have to use lots of
> copyinstr()s.
>
> Interesting though, I ended up porting some d
On Jul 14, 2008, at 3:42 AM, Jon Haslam wrote:
> Tracing Fans,
>
> I know it's been a long time in coming but the CPU Performance
> Counter (CPC) provider is almost here! The code is currently in
> for review and a proposed architecture document is attached here
> for review.
Very cool :
On Jul 15, 2008, at 1:27 PM, James McIlree wrote:
>
> Some of the more exotic cache behavior counters might fire only 1-2k
> events
> per second, though. When you combine that with the need for the
> counter to fire while
> inside the application you are interested in, a
Here is an interesting one :-). Unfortunately I can't pass along a
test case, but I think
visual inspection of the code will be enough to see that f can be
beyond format[0] when
the snprintf() is called.
James M
+++ ./libdtrace/dt_printf.c 2008-07-28 16:54:04.0 -0700
I have a user that was adding some rather expensive probes to library
code.
Their code ended up factoring in such a way that the main line code
had IS_ENABLED()
tests guarding calls to another function that did the real work of
argument construction
and calling the actual dtrace prob
On Nov 19, 2008, at 1:15 PM, Benjamin Smedberg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jonathan Adams wrote:
>
>> This sounds like a bug in the MacOS implementation; from the
>> Dynamic Tracing
>> Guide:
>>
>> http://docs.sun.com/app/docs/doc/817-6223/6mlkidloj?l=en&a=view
I think this is a bug, but I wanted to double check...
A user reported that the -Z flag wasn't working correctly,
and I have narrowed it down to this test case (on Solaris):
/*
* Fully specified, no errors
*/
/home/ovrskeek# dtrace -Z -n 'pid$target:libc.so.1:malloc:entry' -c
On Dec 8, 2008, at 12:40 AM, Alex Peng wrote:
> Hi,
>
> To use DTrace on some C++ code, I found that Apple's implementation
> had another option "-xmangled".
>
> Its usage could be found here:
> http://blog.mozilla.com/dmandelin/2008/02/14/dtrace-c-mysteries-
> solved/
>
> And it could be foun
I'm looking at a hang/stall while dtrace'ing on heavily loaded systems.
I've got the following scenario:
Kernel Thread A is waiting to acquire tthe dtrace_meta_lock
Kernel Thread B owns the dtrace_meta_lock, and is waiting on the
dtrace_provider_lock
Kernel Thread C owns the d
Is proc:::start expected to fire before the first instruction of an
exec'd process is executed, or
only on "new" (processes with a different pid) processes?
James M
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
On Apr 22, 2009, at 1:52 PM, Robert Kern wrote:
I cannot seem to probe any of the Python interpreter's C functions
on OS X.
$ sudo dtrace -n 'pid$target::PyEval_EvalFrameEx:entry' -c python
dtrace: invalid probe specifier pid
$target::PyEval_EvalFrameEx:entry: probe description
pid59706:
There is currently no way to build ustack helpers on OS X.
James M
On Apr 23, 2009, at 1:17 PM, Robert Kern wrote:
I am trying to integrate John Levon's ustack() helper for Python
into the upstream Python sources. The method for doing this on
Solaris is to compile the phelp
On Aug 28, 2009, at 5:33 PM, Mike Shapiro wrote:
On Sat, Aug 29, 2009 at 01:23:34AM +0100, Joel Reymont wrote:
Adam,
I heard from Brendan Gregg that you implemented some tricky code to
make sure dtrace got in very early in the process with -c ...
Can those tricks be implemented to catch a pr
On Sep 9, 2009, at 12:47 PM, Joel Reymont wrote:
I'm trying to time a function within Firefoxwith a pid$target probe
[2]. e.g
dtrace -Zqw -x dynvarsize=64m -x evaltime=preinit -p 13954 -s menu-
construct.d -s sigcont.d
elapsed: 12.7942481ms
cpu: 7.7911194ms
count : 40 times
I'm also
On Sep 9, 2009, at 2:02 PM, Joel Reymont wrote:
James,
On Sep 9, 2009, at 9:58 PM, James McIlree wrote:
I think the extra startup time you are seeing is related to dtrace
processing
the newly loaded libraries.
Can this be worked around by using evaltime=postinit or, perhaps,
evaltime
On Sep 9, 2009, at 2:10 PM, Joel Reymont wrote:
I'm wondering about my use, though. Is the following significantly
more efficient than pid$target::FunName:entry and return?
The cost of the actual probe firing is the same.
The *eval-time* cost of finding out which probes exist and t
On Sep 9, 2009, at 3:18 PM, Joel Reymont wrote:
James,
I thought preinit was the standard evaltime. Am I wrong?
Is it different on Snow Leoapard?
I believe it is postinit on SnowLeopard.
James M
___
dtrace-discuss mailing list
dt
Try adding -xmangled to your command line.
James M
On Sep 11, 2009, at 4:31 PM, Joel Reymont wrote:
On Sep 12, 2009, at 12:28 AM, Jonathan Adams wrote:
dtrace -l -n 'whatever'
where 'whatever' is the full probe spec for nsComponentManagerImpl??
GetService*.
Then, pick o
On Sep 14, 2009, at 9:01 AM, Joel Reymont wrote:
Does dtrace have a problem catching the return from memset on Mac OSX?
The script below catches the entry just fine but the return clause
is never entered.
Thanks, Joel
DTrace thinks its seeing a jump table:
sh-3.2# dtrace
On Oct 23, 2009, at 8:55 AM, Max wrote:
Hi Folks,
I'm trying to get to grips with dapptrace, running it on my Mac.
Everything seems pretty straightforward, except for - of course -
what I'm trying to do.
I want to focus in on my code but I can't seem to be able to output
just the functio
The probefunc length is currently hardcoded. You'd have to rebuild the
kernel to change it.
James M
On Nov 27, 2009, at 4:51 PM, Joel Reymont wrote:
> Is there a setting I can use to make sure probefunc is not cut off at 127
> characters?
>
> Thanks, Joel
>
>
On Apr 20, 2010, at 7:31 AM, Josh ben Jore wrote:
> Hi,
>
> perl-5.12.0 has apparently integrated Alan Burlison and Richard Dave's
> patches to add sub-entry and sub-return probes. I'm so far unable to get this
> to work. I compiled Perl-5.12.0 with -Dusedtrace and tried all the default
> exa
Eric,
What is the dtrace command you were using when you got the error you're
seeing against the release build?
James M
On May 7, 2010, at 9:13 AM, Eric Gorr wrote:
> First, I am using Mac OS X 10.6.3. I am still fairly new to DTrace.
>
>
> For the release build of my applica
;
>
>
> On May 7, 2010, at 1:37 PM, James McIlree wrote:
>
>> Eric,
>>
>> What is the dtrace command you were using when you got the error you're
>> seeing against the release build?
>>
>> James M
>>
>> On May 7, 2010,
On May 7, 2010, at 11:41 AM, Eric Gorr wrote:
> Again, I am using Mac OS X 10.6.3.
>
>
>
> First, I am curious, how is DTrace getting the function name information for
> a release build when all of it's symbols have been stripped from it and there
> is not dSym file either in the application
On May 9, 2010, at 4:46 AM, Eric Gorr wrote:
>>
>> DTrace from the command line doesn't know about the probes.
>>
>> Why is that?
>
> Well, the answer finally came to me... I needed to do:
>
> ~ $sudo dtrace -l -n 'DTraceTest*:::'
>
> Password:
> ID PROVIDERMODULE
Hans,
This is a bug in the OS X dtrace:
Dtrace finishes execution of binary before
creating probes when using -c option
There is a "workaround" of sorts, which is adding the following flags:
-xevaltime=exec -Z
That tells dtrace to start tracing from th
On Mar 26, 2011, at 6:07 PM, Adam Leventhal wrote:
> Hey Adam,
>
> As you probably figured out, those two stacks contain a bunch of JITed
> code. The hotspot JVM should provide the facilities for DTrace to
> interpret those symbolically. Printing of C symbols use an orthogonal
> -- and far simpl
On Mar 28, 2011, at 1:23 PM, Adam Cath wrote:
> Bummer. Whose bugbase are we talking about, and is it open?
It's an Apple bug, I believe the access site is bugreport.apple.com
You will need an ADC membership, I think this is still the current
registration site: http://develope
I'm not able to reproduce, what compiler are you using?
James M
On Jul 27, 2011, at 4:00 PM, Brendan Gregg wrote:
> G'Day,
>
> The way isenabled probes are compiled on Mac OS X Lion has changed in a way
> that dosen't compile (at least, with some compilers). Here's the test t
ndan Gregg wrote:
> Oh, is this a gcc issue? Does xcode handle it ok?
>
> Brendan
>
> On Thu, Jul 28, 2011 at 5:07 AM, James McIlree wrote:
>
> I'm not able to reproduce, what compiler are you using?
>
> James M
>
> On Jul 27, 2011, at 4:00 PM,
68 matches
Mail list logo
