Rivet is hosted by Hepforge, IPPP Durham

Changes between Version 18 and Version 19 of TroubleShooting


Ignore:
Timestamp:
Sep 8, 2016, 10:25:40 PM (15 months ago)
Author:
buckley
Comment:

Help for debugging and upgrading

Legend:

Unmodified
Added
Removed
Modified
  • TroubleShooting

    v18 v19  
    1313
    1414
    15 == "internal constants have been clobbered" error from {{{make-plots}}} / {{{rivet-mkhtml}}}
    1615
    17 The rendering backend for the Rivet plotting system is LaTeX, which produces very nice output but suffers from the limitations and idiosyncracies of a system little changed since the 1970s. In particular, TeX was written in an era when systems with megabytes let alone gigabytes of RAM was inconceivable, and it has a fundamental memory size limitation... whose value is unfortunately system-dependent. You may encounter problems with this if writing LaTeX documents with lots of floating figures in a row: TeX will give up and ask you to give it some manual help.
     16== I just installed a new Rivet version and now it segfaults/crashes when I try to list analyses ==
    1817
    19 For making plots with lots of points and lines, we need to tell LaTeX to allocate more memory than the usual system default. This is done via the {{{$prefix/share/Rivet/texmf/cnf/texmf.cnf}}} that Rivet installs. But on some systems the value that we set may be too high (as mentioned, it's not possible to work out a universally good value) and this produces the strange TeX error "Ouch---my internal constants have been clobbered" (see http://tex.stackexchange.com/questions/67014/latex-gives-me-the-error-ouch-my-internal-constants-have-been-clobbered). To fix this, you should open the {{{texmf.cnf}}} file mentioned above and reduce the value of the {{{main_memory}}} value that it sets: a suggested lower value is 12000000, but you may want to experiment a little to find a near-maximum value for your system.
     18Do you have private analyses, i.e. ones you wrote/downloaded and built yourself, in addition to those which came built-in to the Rivet system? This is usually the problem.
     19
     20Compiled analysis plugins are code libraries, and they are sensitive to the version of Rivet, because our binary interface can change a bit even with minor release updates. So when you upgrade the core Rivet library, your private analysis plugin libraries go out of date and can potentially crash Rivet when it tries to load them.
     21
     22The solution is to delete or rebuild your private {{{Rivet*.so}}} plugins using the currently installed version of {{{rivet-buildplugin}}}. If it still crashes, maybe you missed one: try unsetting the {{{RIVET_ANALYSIS_PATH}}} shell environment variable. If it *still* crashes, maybe we did screw up and some *system* plugin from the previous version hasn't been overwritten. You could try a {{{make uninstall}}} in the previous version's build directory if you still have that, but I tend to just delete all {{{$prefix/lib/Rivet*.so}}} files and the {{{$prefix/lib*/python*/site-packages/rivet*}}} dirs/files from my install area, and reinstall the latest version (this should be quick, since no rebuilding is needed). Sometimes the personal touch is best...
     23
     24
     25== Running gdb on Rivet ==
     26
     27gdb can be a handy tool for debugging fiddly analysis code... although we hope it wasn't the Rivet design that forced you to do fiddly things: please complain if it was. However, running gdb on the usual {{{rivet}}} program does not work straightforwardly, because that's a Python script rather than a compiled binary.
     28
     29Personally, I use this sort of command: {{{gdb --arvgs python `which rivet` --analysis FOO}}}. It finds the absolute paths to {{{python}}} and {{{rivet}}}, and runs gdb on the Python executable with the Rivet script and its options treated as arguments to {{{python}}}. You can do something similar via {{{gdb python}}} and passing the {{{rivet}}} path and arguments to the gdb shell's {{{run}}} command.
     30
     31Another route is to use the {{{rivet-nopy}}} program, which will be found in the bin directory of the Rivet build dir -- note, it is *not* installed to the $prefix dir like {{{rivet}}}, etc.. This *is* a compiled program which allows you to run Rivet analyses without any Python involvement, but its functionality is very limited -- hence we don't install it and only recommend using it if all else fails.
    2032
    2133
     
    3143
    3244
     45== "internal constants have been clobbered" error from {{{make-plots}}} / {{{rivet-mkhtml}}}
     46
     47The rendering backend for the Rivet plotting system is LaTeX, which produces very nice output but suffers from the limitations and idiosyncracies of a system little changed since the 1970s. In particular, TeX was written in an era when systems with megabytes let alone gigabytes of RAM was inconceivable, and it has a fundamental memory size limitation... whose value is unfortunately system-dependent. You may encounter problems with this if writing LaTeX documents with lots of floating figures in a row: TeX will give up and ask you to give it some manual help.
     48
     49For making plots with lots of points and lines, we need to tell LaTeX to allocate more memory than the usual system default. This is done via the {{{$prefix/share/Rivet/texmf/cnf/texmf.cnf}}} that Rivet installs. But on some systems the value that we set may be too high (as mentioned, it's not possible to work out a universally good value) and this produces the strange TeX error "Ouch---my internal constants have been clobbered" (see http://tex.stackexchange.com/questions/67014/latex-gives-me-the-error-ouch-my-internal-constants-have-been-clobbered). To fix this, you should open the {{{texmf.cnf}}} file mentioned above and reduce the value of the {{{main_memory}}} value that it sets: a suggested lower value is 12000000, but you may want to experiment a little to find a near-maximum value for your system.
     50
     51
    3352== SELinux security warnings ==
    3453