[Rivet] bug

[Andy Buckley]

Hi Frank,

I've been in touch with Holger about the problem -- last I heard your
problems came from running events with massless stable partons into
Rivet and filling NaN values into histograms. That's not something we
can test for, and I think YODA was/is right to abort when it gets a
crazy fill value that invalidates the histogram.

This error looks different but is hard to read -- it looks like
something goes wrong inside a Boost shared pointer header. I don't see a
"px != 0" assert anywhere in that analysis code, so is this a private
version of it? Unless that assert is in the Boost code and it's just a
coincidence that they used a physicsy variable name like px...

Duplicate analysis warnings are entirely intentional, and if you are
getting those it suggests that you are using a hacked copy of a standard
analysis and the system is warning that there is another one of the same
name later in the search path. Is that possible?

I ran this analysis happily a few days ago when discussing with Holger,
and it worked fine. I'm on the Rivet trunk of course, but I don't think
there should be any significant changes w.r.t. 2.1.2  (not 2.0.0,
right?)  Certainly no changes in how histogram pointers are handled :-S

Andy


On 11/08/14 16:31, Frank Krauss wrote:
> Dear All,
> as Holger already knows, there are more and more bugs cropping up in
> Rivet + Yoda.
> They manifest themselves as
> 
> 
> Sherpa:
> /home/krauss/rivetinstall/local/include/boost/smart_ptr/shared_ptr.hpp:653:
> typename boost::detail::sp_member_access<T>::type
> boost::shared_ptr<T>::operator->() const [with T = YODA::Histo1D,
> typename boost::detail::sp_member_access<T>::type = YODA::Histo1D*]:
> Assertion `px != 0' failed.
> 
> Exception_Handler::SignalHandler: Signal (6) caught.
>    Cannot continue.
> Exception_Handler::GenerateStackTrace(..): Generating stack trace
> {
>   0x7fb8d9ec54f5  in 'gsignal' (raise.c:64)
>   0x7fb8d9ec8c5b  in 'abort' (abort.c:93)
>   0x7fb8d680fe61  in 'Rivet::CMS_2010_S8547297::analyze(Rivet::Event
> const&)'
>   0x7fb8d8af09d0  in 'Rivet::AnalysisHandler::analyze(HepMC::GenEvent
> const&)'
>   0x7fb8d8dacb1c  in 'Rivet_Interface::Run(ATOOLS::Blob_List*)'
> (basic_string.h:288)
>   0x7fb8dc031bef  in 'SHERPA::Analysis_Phase::Treat(ATOOLS::Blob_List*,
> double&)' (Analysis_Phase.C:66)
>   0x7fb8dc00d2c3  in 'SHERPA::Event_Handler::AnalyseEvent(double&)'
> (Event_Handler.C:145)
>   0x7fb8dc011b57  in
> 'SHERPA::Event_Handler::GenerateMinimumBiasEvent(SHERPA::eventtype::code&)'
> (Event_Handler.C:329)
>   0x7fb8dc012bf5  in
> 'SHERPA::Event_Handler::GenerateEvent(SHERPA::eventtype::code)'
> (Event_Handler.C:127)
>   0x7fb8e67dfc7b  in 'SHERPA::Sherpa::GenerateOneEvent(bool)'
> (Sherpa.C:197)
>   0x402177        in 'main' (Main.C:37)
> }
> 
> 
> So, apparently, your ** new ** ** default ** 2.0.0 which I accessed
> through the bootstrap script by now has some interesting behaviour.
> Before that, there have already been little nuisances, like double
> analyses warnings etc., but no outright crashes.  I seriously suggest
> you try to fix this and do some minor testing next time, before rolling
> out new versions.
> 
> Best wishes
>    Frank
> 


-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN