[Rivet] debugging Rivet

[Andy Buckley]

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