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 with new
|
static PyObject* assignImpedance(PyObject *self, PyObject *args){ |
|
_zImped_n = new std::complex<double>[nBins / 2]; |
If the length of the sequence is greater than
nBins/2 - 1 then some elements are written out of buffer region.
This happens because
assignImpedanceValue function offsets incoming data by one
|
_zImped_n[n + 1] = std::complex<double>(real, imag); |
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
from spacecharge import LSpaceChargeCalc
from orbit.space_charge.sc1d import SC1D_AccNode
b_a = 10.0 / 3.0
length = 248.0
use_spacecharge = 1
min_n_macros = 1000
n_long_slices = 64
position = 124.0
Z = 32 * [complex(0., 0.)]
sc_node_long = SC1D_AccNode(b_a, length, min_n_macros, use_spacecharge, n_long_slices)
sc_node_long.assignImpedance(Z)
Same situation happens in LImpedance class
|
void LImpedance::assignImpedanceValue(int n, double real, double imag) |
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_nmemory buffer allocated withnewpy-orbit/src/spacecharge/wrap_lspacechargecalc.cc
Line 63 in 7916ee3
py-orbit/src/spacecharge/LSpaceChargeCalc.cc
Line 43 in 7916ee3
If the length of the sequence is greater than
nBins/2 - 1then some elements are written out of buffer region.This happens because
assignImpedanceValuefunction offsets incoming data by onepy-orbit/src/spacecharge/LSpaceChargeCalc.cc
Line 83 in 7916ee3
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
LImpedanceclasspy-orbit/src/orbit/Impedances/LImpedance.cc
Line 81 in 7916ee3
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
assignImpedanceValuewith unacceptably long sequence of impedances.