[Halld-offline] Fwd: r7587 - trunk/sim-recon/src/libraries/TRACKING

[David Lawrence]

Hi All,

     I've just committed a fix to the seg. fault/hang problem based on 
Richard's analysis. This is slightly different than the fix Richard 
suggested. It avoids the 80bit/64bit comparison issue by pre-calculating 
the values to be compared rather than doing it in the sort algorithm 
itself. This should also speed things up a little since DVector3::Perp() 
is not being called repeatedly during the sort for the same object.

     I have been able to run through my one reliably-problematic event 
using the new code without any problem. If anyone notices an issue, 
please let me know.

     This problem has been marked as resolved in Mantis.

Regards,
-David

-------- Original Message --------
Subject: 	r7587 - trunk/sim-recon/src/libraries/TRACKING
Date: 	Thu, 17 Mar 2011 11:16:40 -0400
From: 	Hall-D.SVN.Repository at jlab.org
To: 	davidl at jlab.org, brash at pcs.cnu.edu, wolin at jlab.org, 
zisis at uregina.ca, mashephe at indiana.edu, remitche at indiana.edu, 
zihlmann at jlab.org, somov at jlab.org, staylor at jlab.org



Author: davidl
Date: 2011-03-17 11:16:39 -0400 (Thu, 17 Mar 2011)
New Revision: 7587

Modified:
    trunk/sim-recon/src/libraries/TRACKING/DTrackCandidate_factory_CDC.cc
Log:
This is a fix for the seg. fault/hang problem that has been plaguing us
for the last ~4 months. It precalculates the values used in the comparison
in the SortIntersections routine to avoid issues with values calculated
with 80bit precision being compared with values having been copied to and
from a 64bit register. See the report on the GlueX wiki here:

http://www.jlab.org/Hall-D/software/wiki/index.php/Diagnosing_segmentation_faults_in_reconstruction_software



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20110317/4ae6ad1f/attachment-0002.html>