[Rivet] Dangerous casting to FinalState

[David Bjergaard]

Hi Frank, Andy,

For the record, I tried the example file and it did crash.  I had forgot
to "make install" after applying Frank's patch.

Cheers,

    Dave

Andy Buckley <andy.buckley at cern.ch> writes:

> On 24/03/15 16:50, Frank Siegert wrote:
>> Thanks David for the feedback.
>> 
>> I'm hoping to get more feedback from the other Riveters as well. Just
>> to recap, there are two issues with my patch:
>> 
>> (i) It's a bit ugly to have to hide this for each derived
>> FinalState explicitly, I don't know whether there is any better way to
>> disallow such "lossy" copying altogether for a base class?
>
> I've not looked in detail, but the second answer here looks like a
> templated generalisation of the catching mechanism:
> http://stackoverflow.com/questions/580375/how-to-generate-a-compiler-warning-error-when-object-sliced
>
> Maybe this could be specialised to FinalState derived classes using
> SFINAE-type template magic: an awful lot can be done with that, and even
> more in C++11... at the cost of some isolated bits of unreadable code.
> Take a look at the return types in
> https://rivet.hepforge.org/trac/browser/include/Rivet/Math/MathUtils.hh
> if you want a flavour of how that looks! No guarantees, though:
> templates & member functions have more restrictions than for free functions.
>
> No way to generate a compiler warning with gcc, unfortunately :-/
>
>> (ii) My example 2c is a bit strange... it compiles fine, but at
>> runtime fails with:
>> Error in MY_RFSTEST2c::init method: No projections registered for
>> parent 0x7fff33dc1630
>> 
>> I'm attaching again the three files from back then in case somebody
>> doesn't find them anymore.
>
> Thanks! I agree this is something to follow up on, to be helpful to our
> users. Blame C++ for making such subtle errors possible... and g++ for
> not (yet) telling them about it.
>
> Andy
>
>
>> On 14 March 2015 at 20:45, David Bjergaard <david.bjergaard at gmail.com> wrote:
>>> Ah,
>>>
>>> Sorry I forgot to "make install" after applying the patch. I can at
>>> least confirm the crash:
>>>> rivet --pwd -a MY_RFSTEST2c zee.hepmc
>>>> Rivet trunk running on machine calypso (x86_64)
>>>> Rivet.Analysis.Handler: WARN  Analysis 'MY_RFSTEST2c' is unvalidated: be careful, it may be broken!
>>>> Error in MY_RFSTEST2c::init method: No projections registered for parent 0x7fff6d42d9a0
>>>
>>> David Bjergaard <david.bjergaard at gmail.com> writes:
>>>
>>>> Hi Frank,
>>>>
>>>> For some reason your test works (with the patch):
>>>>> rivet --pwd -a MY_RFSTEST2c zee.hepmc
>>>>> Rivet trunk running on machine calypso (x86_64)
>>>>> Rivet.Analysis.Handler: WARN  Analysis 'MY_RFSTEST2c' is unvalidated: be careful, it may be broken!
>>>>> Reading events from 'zee.hepmc'
>>>>> zfinder: -11 10022
>>>>> zfinder: 11 10021
>>>>> rfs.size = 8
>>>>>   rfs[0] = 2103 10006
>>>>>   rfs[1] = 2 10007
>>>>>   rfs[2] = 2103 10009
>>>>>   rfs[3] = 2 10010
>>>>>   rfs[4] = 21 10015
>>>>>   rfs[5] = 21 10016
>>>>>   rfs[6] = -4 10017
>>>>>   rfs[7] = 4 10018
>>>>> Finished event loop
>>>>> Rivet.Analysis.Handler: INFO  Finalising analyses
>>>>> Rivet.Analysis.Handler: INFO  Processed 1 event
>>>>
>>>>> The MCnet usage guidelines apply to Rivet: see http://www.montecarlonet.org/GUIDELINES
>>>>> Please acknowledge plots made with Rivet analyses, and cite arXiv:1003.0694 (http://arxiv.org/abs/1003.0694)
>>>>> Cross-section = 1.515878e+03 pb
>>>> I wonder if its a compiler difference?
>>>>> g++ --version
>>>>> g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2
>>>>> uname -a
>>>>> Linux calypso 3.13.0-46-generic #77-Ubuntu SMP Mon Mar 2 18:23:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>>
>>>> Cheers,
>>>>
>>>>     Dave
>>>>
>>>> Frank Siegert <frank.siegert at cern.ch> writes:
>>>>
>>>>> Hi David,
>>>>>
>>>>> Thanks for your feedback.
>>>>>
>>>>>> Just thinking out loud:
>>>>>> addProjection is templated on a reference, is it possible to make a
>>>>>> specialized template for the non-reference version?
>>>>>>
>>>>>> Something like:
>>>>>>     template <typename PROJ>
>>>>>>     const PROJ& addProjection(const PROJ proj, const std::string& name) {
>>>>>>       std::cerr<<"Please be careful about using references!"<<std::endl;
>>>>>>       return proj;
>>>>>>     }
>>>>>
>>>>> But we would not want to prevent *registering* projections by copy,
>>>>> since that's in general absolutely fine, right? It's rather the
>>>>> copying of a derived projection, e.g. VetoedFinalState, into a
>>>>> FinalState that seems dangerous to me.
>>>>>
>>>>> I have just tested that it's possible to hide the copy constructor,
>>>>> and am attaching a patch for Rivet which shows how this would work in
>>>>> real life. It's a bit ugly to have to hide this for each derived
>>>>> FinalState explicitly, I don't know whether there is any better way to
>>>>> disallow such "lossy" copying altogether for a base class?
>>>>>
>>>>> With this patch Rivet compiles fine, and a few of the typical ZFinder
>>>>> analyses seem to work as expected. Furthermore, an accidental VFS ->
>>>>> FS copying like in my Example 1 now fails as expected and 2a and 2b
>>>>> work as expected. But 2c is a bit strange... it compiles fine, but at
>>>>> runtime fails with:
>>>>> Error in MY_RFSTEST2c::init method: No projections registered for
>>>>> parent 0x7fff33dc1630
>>>>>
>>>>> I don't at all understand where that's coming from, but there is a lot
>>>>> of casting in the projection registration going on. Any ideas? I'm
>>>>> attaching a simple analysis that demonstrates this behaviour, together
>>>>> with one Zee event for testing.
>>>>>
>>>>> Cheers,
>>>>> Frank
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Rivet mailing list
>>>>> Rivet at projects.hepforge.org
>>>>> https://www.hepforge.org/lists/listinfo/rivet