smithuns's blog

Many people suppose that C/C++ is dead with the advent of Java. However, C/C++ applications are still continued to be developed and deployed. Several applications such as MySQL, PhP, Java, etc. are still developed and deployed in C/C++. With DTrace, the possibilities of tracing applications and gaining an overview in a "non-destructive" way, has opened the opportunities for its usage on production quality systems. From a developer perspective, you could incrementally introduce DTrace probes in the critical paths of your code. Typically, 20% of a software's lifetime lies in the developmental phase and 80% of it is in maintainence.

To ease the debugging of applications, be it on a development system or on a production machine, DTrace offers you wide possibilities. However, the problem is not that simple. When considering C/C++, the way DTrace handles them differently. This is because of the name-mangling phenomenon, that flattens the namespaces of C++ applications. Why should this be done?

UNIX is a flat world too. UNIX understands flat namespaces and was developed or is still developed with the C-language and as a result has a flat namespace. C++ offers the hierarchial namespaces, whereby its possible to organize information in a hierarchial way. UNIX does not understand this hierarchy. Thats a problem! C++ overcomes this by flattening the namespace that makes UNIX happy. This phenomenon is called the name-decoration or name-mangling or namespace mangling and so on.

Let me illustrate this with a small program, written in C and compiled with the Sun Studio compiler ( C & C++ compilers). Lets us call this program hallo.c which has nothing spectacular, but has a simple function, void printHallo(int), taking an integer argument. This function prints the word, "Hallo", n-times depending upon the argument you pass to this function. The program listing is as follows:

meson:/export/home/mithun/USDT >more hallo.c
#include

void printHallo(int);

In June 2007, I and a couple of my colleagues at Sun Microsystems Germany organized a "Code Camp" on Optimal Resource Utilization with Zones and Zfs. The Code Camp was very successful and the materials are widely requested.

The main document illustrating the concepts is the "Walkthrough" document. You shall find the document in this blog post.

During the Code Camp we organize in Germany, one of our ISVs had a particular need to determine the stack size of a multi-threaded application and from that information, restrict the stack size.

The stackdepth variable is not the key to the problem we are looking at. To get the stack size, one could use an one-liner:

dtrace -n 'on-cpu { @[execname] = max(curthread->t_procp->p_stksize); }'

For multithreaded programs, this would fail for apparent reasons. We are not taking the self variable into consideration, which would make the collected data erroneouw. We are not using any king of thread locality here. So, the solution we are looking for is something like this:

#!/usr/sbin/dtrace -s
this uintptr_t stkinfoptr;
this uintptr_t stkptr;

sched:::on-cpu, profile:::profile-997{
this->stkinfoptr = 0;
this->stkptr = 0;
}

sched:::on-cpu, profile:::profile-997
/execname != "sched"/{
this->stkinfoptr = curthread->t_lwp->lwp_ustack;
this->stkptr = (uintptr_t)0;
}

sched:::on-cpu, profile:::profile-997
/this->stkinfoptr != 0 && curpsinfo->pr_dmodel == PR_MODEL_ILP32/{
this->stkinfo32 = *(stack32_t *)copyin(this->stkinfoptr,
sizeof (stack32_t));
this->stktop = (uintptr_t)this->stkinfo32.ss_sp +this->stkinfo32.ss_size;
this->stkptr = (uintptr_t)uregs[R_SP];
}

sched:::on-cpu, profile:::profile-997
/this->stkinfoptr != 0 && curpsinfo->pr_dmodel == PR_MODEL_LP64/{
this->stkinfo = *(stack_t *)copyin(this->stkinfoptr,
sizeof (stack_t));
this->stktop = (uintptr_t)this->stkinfo.ss_sp +this->stkinfo.ss_size;
this->stkptr = (uintptr_t)uregs[R_SP];
}

sched:::on-cpu, profile:::profile-997
/this->stkptr != 0/{
@a[execname] = quantize(this->stktop - this->stkptr);
}

dtrace:::ERROR{
@b[execname] = count();
}

dtrace:::END{
printa(@a);
printf("\nErrors: \n" ) ;
printa(" %@d %s\n", @b);
}