<div dir="ltr">Hi Offliners,<div><br></div><div>I've just checked in a fix for the mcsmear crashes that some of you were seeing that resulted in truncated mcsmear output. Some details of the problem and its fix are given below. Please let me know if you see any more similar problems.</div><div><br></div><div><br></div><div>Details: </div><div><br></div><div>Back in last October, during the first detcom simulation run, it was noticed that many jobs were crashing at the mcsmear stage, with a truncated output file. This behavior was noticed by others later on (e.g. <a href="https://halldweb1.jlab.org/mantisbt/view.php?id=424">https://halldweb1.jlab.org/mantisbt/view.php?id=424</a> ). David Lawrence identified the proximate cause as due to a string field of DBCALSiPMSpectrum objects being read in with a length of -1. In HDDM I/O, string lengths are treated as unsigned ints, so this resulted in the program assuming an extremely long string length, which overflowed buffers all over the place.</div><div><br></div><div>I checked that the hdgeant output files were uncorrupted and didn't contain the -1 length values, but was eventually able to determine that the problem came from reading in very long strings from the HDDM files generated by hdgeant. Figuring out the ultimate cause was very difficult because (1) there is no error checking done for input/output on uncompressed HDDM files, (2) whatever error apparently overwrote memory in a difficult to diagnose way, so it was difficult to get any information out of the istream objects. </div><div><br></div><div>Changing the size of the input buffer used to read in the files didn't fix the problem, so instead I changed the coding of the DBCALSiPMSpectrum string to store <span style="font-size:13px">consecutive 0 values as "X<N>", where <N> is the number of zeros, since the long strings were dominated by these strings of zeros. In some limited testing, this seems to have fixed the mcsmear crashes, and should provide a mild reduction in size of the output files.</span></div><div><span style="font-size:13px"><br></span></div><div>I think that this problem is peculiar to the output of HDGeant 3, since I believe it is the only program which still produces uncompressed HDDM files.</div><div><br clear="all"><div><br></div><div>Cheers,</div><div>Sean</div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Sean Dobbs<br>Department of Physics & Astronomy <br>Northwestern University<br>phone: 847-467-2826</div></div>
</div></div>