[Rivet] debugging Rivet

James William Monk xls701 at ku.dk
Tue Oct 27 20:14:47 GMT 2015


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



More information about the Rivet mailing list