[Rivet] debugging Rivet

[James Monk]

Thanks Andy - rivet-nopy was exactly what I need (I remembered that something like that existed at one point, but not the exact details)

cheers,

James


On 27 Oct 2015, at 21:36, Andy Buckley <andy.buckley at cern.ch> wrote:

> To run gdb on a program executed via Python, I have this alias which might help:
> 
> andy at duality:~$ type pygdb
> pygdb is a function
> pygdb ()
> {
>    cmd=$1;
>    shift;
>    gdb -quiet --args python `which $cmd` $*
> }
> 
> We also have the rivet-nopy program as a direct C++ way of running Rivet for exactly this reason. I think we avoid installing it these days, but it should be present in the builddir/bin directory.
> 
> Run like this:
> 
> andy at duality:~/.../rivet-default$ bin/rivet-nopy
> Usage: /home/andy/proj/hep/rivet-default/bin/.libs/lt-rivet-nopy <hepmcfile> <ana1> [<ana2> ...]
> 
> Hope that helps,
> Andy
> 
> 
> On 27/10/15 20:14, James William Monk wrote:
>> Thanks David, though I’m afraid that doesn’t seem to reveal the source of the seg fault.
>> 
>> I am actually speculating a bit that it is a vector bounds problem - the crash actually happens when the analyze method goes out of scope when a bunch of destructors get called, so I’m assuming it’s an array problem, but I suppose it could be some internal pointer to HepMC thing (which just makes it even harder to find).
>> 
>> cheers,
>> 
>> James
>> 
>> 
>> 
>> On 27 Oct 2015, at 20:28, David Bjergaard <david.bjergaard at gmail.com> wrote:
>> 
>>> 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
>> 
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> https://www.hepforge.org/lists/listinfo/rivet
>> 
> 
> 
> -- 
> Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow