lrowaccal crashes, lrowaccal and lronaccal throw SPICE errors when run repeatedly via GUI

[rvwagner]

ISIS version(s) affected: 3.9.1 (Linux), 3.10.1 (MacOS), 4.2.0 (MacOS)

Description
If you have not downloaded the LRO kernels, when you use the GUI version of lrowaccal or lronaccal, if you run it twice without quitting the GUI in between (even if you change the source and destination files), on the second run, it throws a SPICE error (cannot find moon_pa_de421_1900-2050.bpc) and does not finish processing. For lrowaccal, if you try a third time, it crashes; for lronaccal, the third time works, then the fourth time gives the SPICE error again, etc.

I don't know why they're even trying to access a kernel file, as they clearly doesn't need that file for the first (apparently successful) run. The command-line versions are unaffected by this, presumably because they only run once.

How to reproduce
Have an Lro data directory set in IsisPreferences that does not contain a kernels directory.

Launch lrowaccal GUI.
Select a WAC image from lrowac2isis
Put in a "to" name

Hit "Run"

• It will process normally

Hit "Run" again

• It will give the following error in a dialog box:
  "ERROR An unknown NAIF error has been encountered. The short explanation provided by NAIF is [SPICE(NOSUCHFILE)]. The Naif error is [The attempt to load "/Volumes/Disk_SSD/ISIS_DATA/lro//kernels/tspk/moon_pa_de421_1900-2050.bpc" by the routine FURNSH failed. It could not be located.] in NaifStatus.cpp at 115."

Hit "Ok", then hit "Run" a third time.

• It will instantly crash, with the following messages on the command line:
  lrowaccal(35202,0x110c735c0) malloc: *** error for object 0x7fff8a513128: pointer being freed was not allocated
  lrowaccal(35202,0x110c735c0) malloc: *** set a breakpoint in malloc_error_break to debug
  Abort trap: 6

For lronaccal, it's the same process, but with less crashing. The first time you hit run, it works fine, the second time it gives the spice error about moon_pa_de421_1900-2050.bpc, the third time it works fine, the fourth time it gives the SPICE error, etc.

Additional context
Conveniently small NAC images to test with:
http://pds.lroc.asu.edu/data/LRO-L-LROC-2-EDR-V1.0/LROLRC_0003/DATA/MAP/2010108/NAC/M126271092LE.IMG
http://pds.lroc.asu.edu/data/LRO-L-LROC-2-EDR-V1.0/LROLRC_0003/DATA/MAP/2010108/NAC/M126271092RE.IMG

Conveniently small WAC image to test with
http://pds.lroc.asu.edu/data/LRO-L-LROC-2-EDR-V1.0/LROLRC_0003/DATA/MAP/2010076/WAC/M123498264ME.IMG

[rvwagner]

This is probably related to #4038 , as the missing SPICE file is one of the ones I needed to add to make the radiometry correction work. This makes it weirder that lrowaccal doesn't complain about the missing file until after it runs the first time, though.

[jessemapel]

This is indeed related to #4038. Both lronaccal and lrowaccal are calling SPICE routines but not checking for any errors afterwards. When you run either program on images that have only been ingested through lro*2isis and do not have the LRO kernels local the programs attempt to load kernels that don't exist. The first time through the program, this results in miniscule distances between the sun and the moon. Then, the calibration multiplies by these values and you end up with all 0 DNs, as indicated in #4038. When I reproduced this and check the NAC and WAC cubes after the first run they were both entirely 0s (and Nulls for WAC). When running on the command line, the program exits after that first run. In the GUI, though, the program doesn't exit and SPICE is still in an error'd state. Once you run the program again, you get strange results out of SPICE and the errors/seg faults you are seeing.

The fix for right now is to check that the SPICE kernels exist before loading them and then check for SPICE errors after loading kernels and trying to get the solar distance. That should "fix" both this and #4038 by erroring instead of returning a bad result. I am unsure of how this will impact multiple runs in the GUI though. We may need to "reset" SPICE somehow if we run into a SPICE error.