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
- 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.
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.