Autobuild & Code Sanity

Under:
This page will contain results from code-sanity tools i.e. tools checking for code syntax, memory leak, profiling etc ... and tips on how to correct those problems.
Most, if not all, pages here are generated automatically. If you encountered an error in the formatting, please send me a note ...



AutoBuild

AutoBuild is a tool which automatically builds/compiles our libraries based on what has been commited during the day. From time to time, please consult those pages and remember the following guideline for code submission idnto the repository :
  • Code submitted to cvs must compile and run under Linux platform.
  • Compilation should not give any serious warnings.

Valgrind

Valgrind is a flexible tool for debugging and profiling Linux-x86 executables. The tool consists of a core, which provides a synthetic x86 CPU in software, and a series of "skins", each of which is a debugging or profiling tool.For more information valgrind, check its documentation page and the quick tutorial for STAR.

Profiling, Valgrind Results

  • Run-time
    Chains   Profiling   Valgrind
    Year 4 Chains
    P2004 EST OShortR V02 Xi2 CMuDst X X
    Full Y4 sim chain X X
    Year 3 Chains
    dAu2003 est beamLine CMuDst X X
    pp2003 eemcD alltrigger trgD X X
    Year 2 Chains
    P2001 X X
    P2001a X X
    pp2001 X X
    Year 1 Chains
    P2000 X X
    p00h X X
    Simulation Chains
    C2001 GeantOut big evout fss fzin rrs srs trs X X
    C2001 GeantOut big evout fss fzin rrs sss trs X X
    ITTF test chains
    TPC based chain X X
    ITTF full chain X X


Profiling using Jprof

On Linux system, Jprof was made available and part of the STAR infrastructure in order to provide basic profiling. This tool is trully simple to use :

  1. Start root4star

  2. Execute
    gSystem->Setenv("JPROF_FLAGS", "JP_START JP_PERIOD=0.001");
    Those flags will start the Jprof timer and signal handler as soon as an instance of Jprof will be created (the instantiation will happen automatically at the next step). The PERIOD is in seconds ; it tells Jprof how often it has examine the stack.

  3. Execute
    gSystem->Load("libJprof");
    This will load the library containing everything you want. A Global symbol will automatically create an instance of the required Jprof class.

  4. Run your usual chain with the desired options

  5. Leave root4star (.q). A file has been created by Jprof and is named jprof-log (yes, it's always the same name).

  6. From the Uglix prompt, do
    % jprof `which root4star` jprof-log >jprof.html

An example of Jprof output for a P2001a has been produced.
The default output displays a Hierarchical Profile and a flat profile. Both format are different and we will briefly explain what they are.

The Hierarchical Profile is a long list of stack segment. Here is an example of such stack.

index Count    Hits Function Name
4644 tph_fit_cluster_
65 tph_
320075 65 4709 mountain_finder_
4550 tph_fit_isolated_cluster_
47 sortti_
11 tpc_pad_time_offset_
10 tpc_time_to_z_
8 tph_weighted_mean_
5 tph_3point_gauss_
4 iucomp_
3 _init
2 StTpcDb::T0(int)
1 StRTpcT0::getT0(int, int) const
1 StRTpcDimensions::zInnerOffset(void) const
1 StTpcCoordinateTransform::zFromTB(int) const
1 lfitw_
For each segment, only one routine/function is displayed with 3 numbers ; this routine/function is the one of interrest. In our example, mountain_finder_ is the function of interrest.
  • The leftmost number is the index number, and is not important ; ignore it.
  • The center number is the number of times this function was interrupted by the timer. In our case, this funtcion was interrupted 65 times.
  • The last number is the number of times this function was in the call stack when the timer went off. For our example we can see that our function was in the call stack for 4709 interrupt ticks, and we interrupted it 65 times.
The center number therefore represents the frequency at wich this function is seen (how often it is called) while the last number is a measurement of that function duration.

The functions listed above the line for mountain_finder_, are the functions which are calling this function. The numbers to the left of these function names are the number of times these functions were in the call stack as callers of mountain_finder_.

The functions listed below the list for mountain_finder_, are the functions this function was calling when the timer went off. The numbers to the left of the function names are the number of times it was in the call stack as a callee of our function when the timer went off. In our example, each of the 4709 times the timer went off and mountain_finder_ was in the call stack it was calling tph_fit_isolated_cluster_.

The Flat Profile is much more straight forward. This portion of the profile indicates which functions were executing when the timer was going off. It is displayed as a list of functions names on the right and the number of times that function was interrupted on the left. The list is sorted by decreasing interrupt count. For example:

Count   Function Name
1459 St_tpcPadPlanes::operator[](int)
1399 StMagUtilities::Interpolate(float *, float *, int, float)
752 memset
740 St_tpcPadPlanes::GetTable(int) const
731 __ieee754_exp
693 StRTpcPadPlane::numberOfPadsAtRow(int) const
623 StFtpcClusterFinder::gauss_2d(int, int, float, float, float, float, float)
508 __xstat
471 StMagUtilities::Interpolate3Dfield(float, float, float, float &, float &, float &)
449 StRTpcPadPlane::numberOfInnerRows(void) const
435 StMagUtilities::Search(int, float *, float, int &)
391 exp
In general, the functions with the highest count are the functions which are taking the most time. The function names are linked to the entry for that function in the hierarchical profile.

We hope you will enjoy profiling and that this tool will help finding the hotest spots.