[Rivet] Minor problems in Rivet 1.5.0

[Andy Buckley]

On 18/03/11 14:40, Leif Lönnblad wrote:
> On 2011-03-18 11:50, Frank Siegert wrote:
>>> * If I add an analysis which gets removed because of the wrong beam
>>> energies I get a seg-fault after the message
>>>
>>> Analysis 'CMS_2011_S8957746' is incompatible with the provided beams:
>>> removing
> 
> 
>> Yep, that seems to be a nasty memory corruption problem that Andy has
>> tried to track down several times and hasn't managed yet (and nobody
>> else dares touching the pointer/projection/... system ;-)). It's on the
>> agenda for 2.0 I believe, and is somewhat related to/tracked in this
>> ticket:
> 
> OK, so I traced the problem to a strange line in
> AnalysisHandler::removeAnalysis:
>    toremove.reset( a.get() );
> 
> According to the boost docs, this means that toremove afterwards thinks
> it is the sole owner of the analysis. But the pointer in the _analysis
> container also thinks it is the sole owner, and when the analysis is
> removed from the container it is deleted. And when the function exits,
> and toremove is destroyed it will try to delete the analysis again,
> thinking it is the only owner. Changing the line to
>    toremove = a;
> solves everything.
> 
> Shall I check it in?

Wow, please do! I thought that reset *was* the Boost shared_ptr way of
assigning a shared ptr value, and was in some way more suitable than the
operator=, cf. operator[] on std::map -- I didn't realise that they had
different semantics about the implied ownership. Seems I have some
re-reading of the Boost pointer definitions to do. Thanks, Leif :)

I believe that there is still a problem in that the projection
shared_ptrs are then put into a std::set, but that operator<(shared_ptr,
shared_ptr) is not quite what you think it should be. But perhaps by
changing the ownership as above, this issue is also resolved: the
comparison operator distinction also related to the ownership.

I can also now test putting back the fixed versions of some singletons
as well... when I tried to do this before, it turned out that cleaning
them up properly resulted in a segfault at the end of every Rivet job!

We'll have to test this a bit, but combined with a few more analyses it
would be a nice thing to have in a 1.5.1 patch release, while we get on
in parallel with histogramming improvements.

Andy

-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.