A sample program CCtest was created to demonstrate an error common to C++ applications — the memory leak. The examples in this article demonstrate the use of the DTrace feature in the Solaris 10 Operating System to diagnose C++ application errors. These examples are also used to compare DTrace with other debugging tools, including Sun Studio 10 software and mdb in the Solaris 10 OS.
Using DTrace to Profile and Debug A C++ Program
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The dtrace programming solution seems a little complex and error prone. The time it takes me to learn dtrace and implement it properly, I could have probably used traditional debugging tools and diagnose the problem.
The C programming language is too complex. The time it takes me to learn C and develop my application, I could have probably used assembly.
Last time I checked, Tim, Dtrace wasn’t a programming language. Your analogies are misplaced, friend.
“Last time I checked, Tim, Dtrace wasn’t a programming language. Your analogies are misplaced, friend.”
actually…it is. Most of using DTrace is using a scripting language called D.
Perhaps you should look at this blog post from one of the architects of DTrace:
http://blogs.sun.com/roller/page/ahl/20041118
While I understamd the reasons for using C & C++, I really am glad that I am fortunate enough to program in an Interpreted language (JIT’ed, I’ll leave you guessing which
). Nothing is more revealing than a stacktrace 
Nothing is more revealing than a stacktrace
Are you sure about that? How about the amount of time
actually spent in a function? Or how frequently a certain
branch gets executed?
I just fire up MallocDebug in OSX … sooo much easier.
/me raises his hand! Well, actually I just -TESTED- an OS, but hey if you don’t think testing is part of development, I got news for ya…
Okay, DTrace is a really cool tool. Linux will spend years catching up in this regard.
But using it to track down a memory leak is a pretty bad example because most people attack that particular issue in already well-established ways.
I wonder if DTrace could help diagnose faulty cache roms…
Doesn’t kprobes already do all that stuff on Linux? I don’t understand why everybody think Linux must always be catching up. Meh
“Okay, DTrace is a really cool tool. Linux will spend years catching up in this regard. ”
thats because of your ignorance regarding kprobes,dprobes and LTT. read them up
> Doesn’t kprobes already do all that stuff on Linux? I don’t understand why everybody think Linux must always be catching up. Meh
> “Okay, DTrace is a really cool tool. Linux will spend years catching up in this regard. ”
> thats because of your ignorance regarding kprobes,dprobes and LTT. read them up
http://www.unixville.com/?q=node/view/104
http://blog.sun.com/roller/comments/bmc/Weblog/dtrace_vs_dprobes_lt…
ttp://berrange.com/bitsbobs/mlp/2004/07/dtrace
The last url is by a redhat employee.
The reason that people are consistantly saying dtrace is miles ahead of Linux debugging tools is that…. it actually is.
Linux is not the best OS at absolutely everything, and in a lot of areas, its tools are subpar. It has no real equivalent to dtrace; kprobes and similar are far inferior.
Dtrace is really, really cool, and well thought out; the linux tools which do similar things are nowhere near as powerful, or as safe to use (dtrace tries to make it hard to accidentally crash your system with a probe.)
I’m primarily a Linux user, and haven’t used Solaris beyond a little bit of playing with Solaris 8 a few years ago.
I think a typical Linux userspace environment is much nicer than a default Solaris one; and Linux has some advantages; in terms of dtrace, though, Solaris is way ahead.
We’ve got two articles from SUN employees claiming that dtrace is better than kprobes, dprobes and LTT. Duh! We’ve got one article from “someone” saying linux has had probing and debugging tools for years, but that Dtrace is better because it combines all these tools into one package.
We’ve got a bunch of comments here saying Linux is “years” behind Solaris because it doesn’t have any tool resembling Dtrace. Do you see why I just don’t understand why Solaris fanatics are just so negative about the capabilities of Linux?
Valgrind (http://valgrind.kde.org/overview.html) is easy to use but also able to do some pretty deep analysis. I found a lot mem-leaks but also possible segfaults and so on with it.
It seems that DTrace is useful for debugging binary executables for which you have no source, so it could be handy for reverse engineering them.
Other than that, I see no practical uses for it.
Tracing allocation is simple to do with a LD_PRELOAD library overriding malloc & co. (or operator new) by functions that print out their ret value (on x86 add 4 to ebp’s value and read from that address) so that you know where the calling code resides.
They have yet to show me a use for this DTrace that I can’t do with gcc/gdb for my own code.
“Do you see why I just don’t understand why Solaris fanatics are just so negative about the capabilities of Linux?”
they are liers. Just hear Jonathan from Sun calling redhat a proprietary distribution and not LSB compliant and laugh off
Do you see why I just don’t understand why Solaris fanatics are just so negative about the capabilities of Linux?
You are the one claiming anyone professing DTrace as a step forward _must_ be wrong (Even if they work for Red Hat) when you are not even familiar with the tool they are commenting on. Then you have nerve to make the claim that _they_ are just Solaris fanatics that just have not seen the Linux light?
Is anyone home?
Why do they have to use yet another script language for it? What make Sun to believe that developers always want to learn yet another language? For god’s sake, take the advantage of one of the several POPULAR script langauge out there!!
D is not new but no one use it.
Jim,
I could care less what anyone professes, but to claim that Linux has no tools like Dtrace, or is “years” behind in developing such tools, is bothering on ignorance.
Oh, and continue to amuse yourself conjuring up statements I never made.
one of the things I like about DTRACE is that people have started writing DTRACE wrappers around standard tools (ps -ef) type of things.
Here is an example that we were able use in an actual case.
—
Large-ish server.. bunch of different programs. (database and a few other fun things…)
Suddenly performance goes into the toilet. Customer/developer calls up, they’re real unhappy, and its obviously all our fault…. ps-ef / top-and-friends don’t show much of anything, but IO-stat shows 2 IO-channels are COMPLETELY on-fire. (causing the rest of the system to run like a dog.)
Great, now which process/app is doing THAT? Not real cool to start shutting them down one at a time till the problem goes away…..
dtrace-ps-ef wrapper to the rescue.
run ps-ef.dtrace, and now there is ANOTHER column in the ps-ef output… a column that says what percentage of IO *that* particular process is taking up….
We took particular joy in calling the (previously unfriendly) developer back to explain exactly which one of HIS processes was causing the problem.
From an Admin perspective, thats the area in which we see the power of dtrace. (yes, its not a trivial tool/language, but anyone can run some canned scripts that can be very powerful)
Developers can use it differently, but I’m not a developper and so not in a good position to comment on the mem-debuggin g etc.
—
1 comment I *can* make…. Someone suggested using LD_PATH etc. modifications to help debug a mem-leak.. yes, that is certainly do-able once you stop and restart the program. One thing DTRACE allows you to do is profile “running” applications without booting into special kernels, restarting apps into profiling harnasses, etc. etc.
If there is a developer on this forum that is familiar with dtrace, please chime in.
People claiming that they can use valgrind or gcd or whatever are missing the real point of dtrace. Imagine you have large production server running hundreds of programs with hundred of users. Some programms you have source for some you don’t. All of a sudden somethings start running slowly some of time for some people with no obvious pattern. Dtrace lets you quickly get to the bottom of the problem without taking the system offline and without affecting performance. No need for source, no need for guessing which binary is guilty, no need for downtime or performance hits, no need for trying to replicate the problem on a test system. That is the strength of dtrace. Valgrind is great, no question about it, but you can’t run it on a production system.
Ya well….Linux doesn’t need nothing like that cause it’s perfect. It never has any problems, and will find and destroy any of the problems you describe because of the sprinkles of magical penquin urine.
Why do people even want to run another OS. Linux is the best at everything. It always has been and always will be. Desktop, Multimedia, web-server, embedded, HPC, mission critical datacenter, etc, etc, etc.
Every time we see an article about another OS or a service it provides, it’s our duty as loyal penquinistas to refute, flame, and annoy.
Sorry, but I have to go now. My mommy is calling me up from my basement apartment for dinner.
LOL!
“What make Sun to believe that developers always want to learn yet another language?”
The script language is basically just like Awk and C. It isn’t counterintuitive at all. Also, name an existing scripting language that has pattern matching to Solaris kernel system calls built in.
“They have yet to show me a use for this DTrace that I can’t do with gcc/gdb for my own code.”
You obviously haven’t looked very hard.
DTrace is a complete programming language that allows you to basically come up with any method of measuring system activity you can imagine. The things that you can’t do with gdb are basically up to you. Also, gdb is really really clunky for understanding the flow of a program, especially if it is multithreaded. DTrace tracks the threads for you and collects the data you want, programatically and repeatably.