A workaround would be increasing buffer size by one, or removing increment in assignImpedanceValue.
Consequences of either workaround are unclear. So one needs to fully test Fourier transform procedure to make sure that result is correct. Also a simple check would be nice to prevent calling assignImpedanceValue with unacceptably long sequence of impedances.
Following function iterates over all elements of input sequence coming from python and puts all elements of the sequence into
_zImped_n
memory buffer allocated withnew
https://github.com/PyORBIT-Collaboration/py-orbit/blob/7916ee32bd92c554e386a3ea81c49e9df67e2a63/src/spacecharge/wrap_lspacechargecalc.cc#L63https://github.com/PyORBIT-Collaboration/py-orbit/blob/7916ee32bd92c554e386a3ea81c49e9df67e2a63/src/spacecharge/LSpaceChargeCalc.cc#L43 If the length of the sequence is greater than
nBins/2 - 1
then some elements are written out of buffer region. This happens becauseassignImpedanceValue
function offsets incoming data by one https://github.com/PyORBIT-Collaboration/py-orbit/blob/7916ee32bd92c554e386a3ea81c49e9df67e2a63/src/spacecharge/LSpaceChargeCalc.cc#L83 It is probably done to match indexing of fftw library calls or coming from FORTRAN? Anyway it causes segfault during program completion (when destructor is called).So the python code below segfaults because it has 32 impedances and 64 longitudinal slices
Same situation happens in
LImpedance
class https://github.com/PyORBIT-Collaboration/py-orbit/blob/7916ee32bd92c554e386a3ea81c49e9df67e2a63/src/orbit/Impedances/LImpedance.cc#L81A workaround would be increasing buffer size by one, or removing increment in
assignImpedanceValue
. Consequences of either workaround are unclear. So one needs to fully test Fourier transform procedure to make sure that result is correct. Also a simple check would be nice to prevent callingassignImpedanceValue
with unacceptably long sequence of impedances.