[Rivet] debugging Rivet

[David Bjergaard]

Hi James,

FWIW, you can compile your rivet plugin without the rivet-buildplugin if you
need something more complicated. My Makefile rule looks like:

RivetMC_GENSTUDY_CHARMONIUM.so:  MC_GENSTUDY_CHARMONIUM.cc libBOOSTFastJets.so
	$(CC) -o "$@" -shared -fPIC $(CFLAGS) $< -lBOOSTFastJets $(LDFLAGS) -lfastjetcontribfragile -L ./

Here I needed to link to another library (libBOOSTFastJets.so), you could also
add debug symbols (-g3 and -O0).  This may help your stack trace.

If your using std::vector<T>::at you won't get a full stacktrace (just an
uncaught exception).  If you use the array access operator[] then you'll get a
bona fide segfault and may get the code stacktrace with line numbers (assuming
the debug symbols are available).

Hope this helps, maybe one of the rivet devs has a better prescription for
loading into real debugger.

    David

James William Monk <xls701 at ku.dk> writes:

> Hi,
>
> Does anyone have a good technique for debugging Rivet?  One downside
> of it running inside a Python shell is that when I have a seg fault
> the only info I get is the line of the python script on which the
> crash happens, which isn’t very enlightening.  Of course I am on a mac
> and therefore using lldb instead of gdb, but there is a Python API for
> all the lldb functionality, so you’d think it would play nicely, but
> doesn’t seem to - all the examples for lldb I have seen assume you
> have a compiled executable that you want to debug interactively from a
> Python shell, not debug the calls to Python bindings themselves.  I
> currently have what looks like a vector out of bounds error, but
> trying to find where it is happening is infuriating!
>
> cheers,
>
> James
>
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet