ioc crash due to arithmetic error in HDF5 plugin

[stuwilkins]

Hey, I found a strange bug that came running the HDF5 plugin. I got to a state where the AD IOC would crash during save/restore restore on boot. I ran it through the debugger and it showed that it got an arithmetic error at this point in the code, presumably because flush is zero.

ADCore/ADApp/pluginSrc/NDFileHDF5.cpp

Line 1457 in 5cd6ee2

if ((numCaptured+1) % flush == 0) {

The fix was to remove all HDF1 PVs from save/restore and all was OK. I am posting to see if this has happened before or if it is 1 in 1e6 ...

[MarkRivers]

That line is in NDFileHDF5::writeFile(). It does not seem correct that writeFile() being called during iocInit().

[stuwilkins]

I agree Mark, but this is where the debugger lead me. Perhaps there was an error with the debugging symbols, but it also reported an arithmetic error which I assume was divide by zero which is consistent with this line.

[MarkRivers]

I suspect the debugger is correct, and for some reason writeFile() is being called at iocInit. Does the HDF5 plugin have AutoSave=1, and does the detector start acquiring immediately when the IOC reboots? If not then I don't understand why writeFile() is being called.

Can you reproduce the problem by using the previous auto_settings.save file? That will make debugging a lot easier.

I just tested with the simDetector and my auto_settings.sav file has NumFramesFlush=0 but the IOC does not crash when I start it.

corvette:simDetectorIOC/iocBoot/iocSimDetector>grep Flush autosave/auto_settings.sav
13SIM1:HDF1:NumFramesFlush 0

Mark

[stuwilkins]

Hi @MarkRivers yes AutoSave=1 and the detector was acquiring immediately because it was in a continuous mode. Perhaps I should block that until after IOC init?

[stuwilkins]

And the IOC did have AutoSave=1

[MarkRivers]

My drivers don't start acquiring until Acquire is set to 1, and I don't normally autosave the value of Acquire. That way on a reboot the detector is stopped.