This article details the use of an open-source multithreaded trace/debug library called CTrace. It also presents a method of remotely tracing a running application by using the SSH protocol.
Tracing multithreaded applications using CTrace
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
CTrace is a good general paradigm; however slightly different implementations may be better in some cases.
For example, the system that I use does not use trace levels, but rather trace “concepts”. Each concept has a unique string name and integer value; this value is used as an index into an array of flags indicating if the given concept is to be traced. In addition, a specific environment variable is defined by convention as a comma separated list of concept names, and is used to set which concepts are set at process startup. Of course, a message-based setting and/or setting in a debugger during runtime may also be used (although we do not typically use the former). We also provide macros to define entire blocks of code (allowing a complete data structure to be traced, for example), and to declare variables needed for this code as well. Of course, we provide an option to conditionally compile these macros into executable code.
Jim
they dont satisfy the same kind of usages. they are targetted as competitors
That doesn’t make sense. If they are competing applications, then the functionality should be similar.
Did you mean to say that they are complementary?
Meant to say “not competitors”
Unfortunately, the comment “DTrace is cooler” was moderated down. Yes, I’m biased, but DTrace is cooler: DTrace is fully dynamic; has zero probe effect when not enabled; can instrument both user-level and kernel-level; can instrument nearly arbitrary kernel context; allows for arbitrary actions; allows for arbitrary predicates; has its own high-level control language; has user-defined variables; supports data aggregation as a first-class citizen; has a mechanism for speculative tracing; has a mechanism for tracing during boot; allows for disjoint instrumentation methodologies; has a scalable architecture; allows for virtualized consumers; and has a scripting capability. CTrace has none of these capabilities — it is very much a traditional tracing framework like the old VTRACE in SunOS or TNF in Solaris. So it that enough supporting detail to avoid being moderated down? One hopes… (And no, the original post was not me…)
While Brian is correct in what he says, CTrace and DTrace are not competing tools. CTrace is portable, while DTrace is Solaris 10 specific. CTrace is lightweight (essentially a set of macros), whice DTrace is a fairly heavyweight system with its own language (“D”, not to be confused with the Walter Bright/Digital Mars effort) and OS kernal support. CTrace is geared toward software developers, who can customize the calls and the CTrace system itself to better support the software which uses it, where DTrace is oriented more to system administrators and more generic views of programs.
On a Solaris 10 platform, there’s no reason not to use both for different purposes. On other OSs, DTrace is not an option.
Jim