<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi, I can't reproduce the error with the HEAD version of rivet and yoda. There are a couple of threads on stackoverflow describing a similar observation when initialising shared_ptr improperly: <blockquote><a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/3541179/shared-ptr-assertion-px-0-failed">http://stackoverflow.com/questions/3541179/shared-ptr-assertion-px-0-failed</a> <a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/5351823/boost-share-ptr-difference-between-operator-and-reset">http://stackoverflow.com/questions/5351823/boost-share-ptr-difference-between-operator-and-reset</a> </blockquote> The only occurence of shared_ptr is in the BinSearcher which calls reset() in the constructor. Not sure if the second thread would be a safer (or even applicable) option, i.e. explicitly calling <blockquote> <pre style="" class="default prettyprint prettyprinted"><code>foo = boost::make_shared<Blah>();</code></pre> </blockquote> Holger On 11/08/14 16:53, Andy Buckley wrote: <blockquote cite="mid:53E8E6EF.6000408@cern.ch" type="cite"> <pre wrap="">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: </pre> <blockquote type="cite"> <pre wrap="">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 </pre> </blockquote> <pre wrap=""> </pre> </blockquote> </body> </html>