I'm trying to learn a bit more about dtrace and I thought that using it to add probes to macruby would be fun. I pulled up the sample dtrace scripts from the Macruby 0.5 b2 source and was working with the script: class World def say(message) puts message end end world = World.new world.say('hello') (taken from http://redartisan.com/2008/5/18/dtrace-ruby) I tried to run the trace as: $ sudo dtrace -s methods_count.d -c "macruby world.rb" (where methods_count.d is one of the sample dtrace scripts) This doesn't produce any meaningful results. After playing around for a bit, I have learned that if I add a bit to the end of my ruby script: while(true) sleep 1 end What I take from that is if the ruby script runs for a longer time, dtrace has a chance plugging into the ruby application which it does not have when the script exits quickly. Am I doing something the wrong way? Is there a better way to ask dtrace to attach to my ruby application and catch information? Scott
Hi Scott, I'm not a DTrace expert but in my experience, dtrace takes a short time to attach to a given process, and if the process exists prematurely it won't work. I'm not aware of any way to work around that, except by patching the process to make it wait a bit more, as you did. This might be a good question for the DTrace list (if there is one!). Laurent On Dec 17, 2009, at 12:21 PM, Scott Thompson wrote:
I'm trying to learn a bit more about dtrace and I thought that using it to add probes to macruby would be fun.
I pulled up the sample dtrace scripts from the Macruby 0.5 b2 source and was working with the script:
class World def say(message) puts message end end
world = World.new world.say('hello')
(taken from http://redartisan.com/2008/5/18/dtrace-ruby)
I tried to run the trace as:
$ sudo dtrace -s methods_count.d -c "macruby world.rb"
(where methods_count.d is one of the sample dtrace scripts)
This doesn't produce any meaningful results.
After playing around for a bit, I have learned that if I add a bit to the end of my ruby script:
while(true) sleep 1 end
What I take from that is if the ruby script runs for a longer time, dtrace has a chance plugging into the ruby application which it does not have when the script exits quickly.
Am I doing something the wrong way? Is there a better way to ask dtrace to attach to my ruby application and catch information?
Scott
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Scott, I have not had any trouble running macruby through dtrace here, can you send the contents of your dtrace script so that I can compare to my working files? Jordan On Dec 18, 2009, at 16:33, Laurent Sansonetti wrote:
Hi Scott,
I'm not a DTrace expert but in my experience, dtrace takes a short time to attach to a given process, and if the process exists prematurely it won't work. I'm not aware of any way to work around that, except by patching the process to make it wait a bit more, as you did.
This might be a good question for the DTrace list (if there is one!).
Laurent
On Dec 17, 2009, at 12:21 PM, Scott Thompson wrote:
I'm trying to learn a bit more about dtrace and I thought that using it to add probes to macruby would be fun.
I pulled up the sample dtrace scripts from the Macruby 0.5 b2 source and was working with the script:
class World def say(message) puts message end end
world = World.new world.say('hello')
(taken from http://redartisan.com/2008/5/18/dtrace-ruby)
I tried to run the trace as:
$ sudo dtrace -s methods_count.d -c "macruby world.rb"
(where methods_count.d is one of the sample dtrace scripts)
This doesn't produce any meaningful results.
After playing around for a bit, I have learned that if I add a bit to the end of my ruby script:
while(true) sleep 1 end
What I take from that is if the ruby script runs for a longer time, dtrace has a chance plugging into the ruby application which it does not have when the script exits quickly.
Am I doing something the wrong way? Is there a better way to ask dtrace to attach to my ruby application and catch information?
Scott
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
I have not had any trouble running macruby through dtrace here, can you send the contents of your dtrace script so that I can compare to my working files?
Thanks to everyone for their suggestions. I was doing the prior work on my office computer (a Mac Pro). I tried the same thing on this computer (a laptop) and it seems to work fine. The dscript I was running wasn't very complicated, it was something like this: -- macruby-dtrace.d -- macruby$target:::method-entry { printf("%s.%s", copyinstr(arg0), copyinstr(arg1)); } macruby$target:::method-return { printf("%s.%s", copyinstr(arg0), copyinstr(arg1)); } The ruby script is: -- macruby-dtrace.rb -- class World def say(message) puts message end end world = World.new world.say('hello') I was able to run this with the command: sudo dtrace -F -s "macruby-dtrace.d" -c "/usr/local/bin/macruby ./macruby-dtrace.rb" On the laptop it works fine. I'll look at the problem again when I get to the office to see if it was some kind of keyboard-chair error. Scott
Hi Scott, On Dec 18, 2009, at 2:33 PM, Laurent Sansonetti wrote:
I'm not a DTrace expert but in my experience, dtrace takes a short time to attach to a given process, and if the process exists prematurely it won't work. I'm not aware of any way to work around that, except by patching the process to make it wait a bit more, as you did.
This might be a good question for the DTrace list (if there is one!).
Most DTrace discussions for Mac OS Xoccur on either the performance-dev: http://lists.apple.com/listinfo/perfoptimization-dev/ or darwin-dev: http://www.lists.apple.com/mailman/listinfo/darwin-dev/ mailing lists. Best, -- Ernie P.
participants (4)
-
Ernest N. Prabhakar, Ph.D.
-
Jordan Breeding
-
Laurent Sansonetti
-
Scott Thompson