Project

General

Profile

Art Tips

Things art doesn't like to go in art records

- std::map (works but poor performance, always use vector)
- Inheritance (even if hidden using "#ifndef GCCXML")
- Virtual destructors (even if hidden using "#ifndef GCCXML"), probably any virtual functions

Random tips

- If using analyzers/outputs (e.g. stuff that goes in "end_paths") in a fcl file that also uses producers/filters, must specify what input path to use using SelectEvents parameter (e.g. which path/stream you want the analyzer/output to take as input), otherwise will use the fcl source and ignore the producer/filter processing.

Trouble-shooting

Crazy art record member variable values

If see member variables in art record have crazy values when browsing in ROOT file (like memory out of range) and cause seg faults in analyzers, might be due to a virtual destructor in your art record class. Remove these.

Missing / wrong member varrables in art record

art seems to have issues picking up changed to art record structures without a full zap an rebuild (e.g. it will build them but the new members won't be there). ALways zap and rebuild after changing a class that is stored as an art record.

glibc error before module even starts

If you see errors like:

*** glibc detected *** gm2: malloc(): memory corruption (fast)

before your module seems to even start, might be because you have more than one module with the same class name (WARNING, class name, not file name), which can happen if you copy and paste an old module to start a new one. As long as they are built in different libraries (e.g. the modules are in different directories), they will compile fine. But at run time if you use both from thr same fcl file then there will be conflicts at fcl parameteparsing time (e.g. in your module constructors). Valgrind can highlight this.

Missing "_module" from module file name

If your art module .cc file does not end in "_module.cc", you will get build errors like this:

RuntimeError: (file "/unix/muons/g-2/gleb/offline/gm2Dev_v6_01_00/build_slf6.x86_64/gm2unpackers/lib/libgm2unpackers_mwpc_dict.so", line -1) Failed to load Dynamic link library /unix/muons/g-2/gleb/offline/gm2Dev_v6_01_00/build_slf6.x86_64/gm2unpackers/lib/libgm2unpackers_mwpc_dict.so

Build fails because it cannot find library

If the build fails at link time because it cannot find the .so file for one of your modules, even though from the CMakeLists.txt it looks like it should be OK (e.g. you;ve added to required products), it might be because add_subdirectory(ups) is above in the line for the directory containing the file you're trying to link against.

Similarly, if you want to develop new code, or move code to a new folder within one of the top level gm2 folders (such as gm2ringsim, gm2tracker), you need to add the correct subdirectory with the needed files to the top level CMakeLists.txt file, such as: add_subdirectory( testgd ). Otherwise you will see an error such as:

If you see something like:
eg. If you see the error :

---- Configuration BEGIN
  Library specification "DummyPlane": does not correspond to any library in LD_LIBRARY_PATH of type "service" 
---- Configuration END

Always put add_subdirectory(ups) last.

Bad version: gm2xxx n.n.n is less than minimum required version

For all repositories/products that rely on gm2xxx then you need to check the version in the top level CMakelist (grep gm2xxx gm2*/CMakelist.txt), it should be changed to which ever version is listed in gm2xxx/ups/product_deps file

Undefined symbol, typeinfo - run time

The CMakelist that is in folder of the module that is running is missing a library. Add it below MODULE_LIBRARIES.

Note: this error can sometimes appear if you have a virtual destructor included in the header file in the library you are attempting to link to.