When the code looks for VFATs and doesn't find them, the values for DAC m and b are defaulted to nan and all processing in these vfats stops working. When the code then goes to plot the graphs, the code segfaults and not plots are made
Types of issue
[x] Bug report (report an issue with the code)
[ ] Feature request (request for change which adds functionality)
Expected Behavior
Because the code segfaults in the drawing of plots, it means one cannot even see information about vfats that are found. A better behaviour is to give error messages about these vfats, maybe give suggested fixes for the user, and still make graphs of the found vfats and exit the code more gracefully
Current Behavior
The code craps out if there is a vfat that has 128 failed fits, ie the vfat isn't found. This is especially important for GE21 plotting since with the DB, since the code looks for vfats in the spots [12-23] and finds nothing, the code potentially fails to make plots for every GE21 root input.
Steps to Reproduce (for bugs)
./anaUltraScurve.py /afs/cern.ch/user/d/dteague/public/GEM_Files/GE21_scurve.root long
Possible Solution (for bugs)
Possibly do some sanitization of the graphs before plotting
Stack trace
#6 0x000000000dc32e60 in ?? ()
#7 0x00007fbe0cc984f3 in FT_Done_Glyph () from /lib64/libfreetype.so.6
#8 0x00007fbe0e51c1e1 in TTF::LayoutGlyphs() () from /usr/lib64/root/libGraf.so.6.12
#9 0x00007fbe0e51cdee in TTF::GetTextExtent(unsigned int&, unsigned int&, char*) () from /usr/lib64/root/libGraf.so.6.12
#10 0x00007fbe0e4f0261 in TLatex::Analyse(double, double, TLatex::TextSpec_t, char const*, int) () from /usr/lib64/root/libGraf.so.6.12
#11 0x00007fbe0e4f11c2 in TLatex::Anal1(TLatex::TextSpec_t, char const*, int) () from /usr/lib64/root/libGraf.so.6.12
#12 0x00007fbe0e4f130d in TLatex::FirstParse(double, double, char const*) () from /usr/lib64/root/libGraf.so.6.12
#13 0x00007fbe0e4f2a20 in TLatex::GetXsize() () from /usr/lib64/root/libGraf.so.6.12
#14 0x00007fbdf6edfc52 in THistPainter::PaintTitle() () from /usr/lib64/root/libHistPainter.so.6.12.06
#15 0x00007fbdf6eb98e3 in THistPainter::PaintTable(char const*) () from /usr/lib64/root/libHistPainter.so.6.12.06
#16 0x00007fbdf6ebb1ee in THistPainter::Paint(char const*) () from /usr/lib64/root/libHistPainter.so.6.12.06
#17 0x00007fbe0df728b9 in TPad::PaintModified() () from /usr/lib64/root/libGpad.so.6.12
#18 0x00007fbe0df72825 in TPad::PaintModified() () from /usr/lib64/root/libGpad.so.6.12
#19 0x00007fbe0df41a4c in TCanvas::Update() () from /usr/lib64/root/libGpad.so.6.12
Brief summary of issue
When the code looks for VFATs and doesn't find them, the values for DAC m and b are defaulted to nan and all processing in these vfats stops working. When the code then goes to plot the graphs, the code segfaults and not plots are made
Types of issue
Expected Behavior
Because the code segfaults in the drawing of plots, it means one cannot even see information about vfats that are found. A better behaviour is to give error messages about these vfats, maybe give suggested fixes for the user, and still make graphs of the found vfats and exit the code more gracefully
Current Behavior
The code craps out if there is a vfat that has 128 failed fits, ie the vfat isn't found. This is especially important for GE21 plotting since with the DB, since the code looks for vfats in the spots [12-23] and finds nothing, the code potentially fails to make plots for every GE21 root input.
Steps to Reproduce (for bugs)
./anaUltraScurve.py /afs/cern.ch/user/d/dteague/public/GEM_Files/GE21_scurve.root longPossible Solution (for bugs)
Possibly do some sanitization of the graphs before plotting
Stack trace