- edited description
Printing of glitch parameters causes a SegFault
From a clean install using c030758e I run into the following problem. If I have a parameter file that looks like, e.g. test.par
containing:
PSRJ J1234+1234
RAJ 12:34:00.0
DECJ 12:34:00.0
F0 123.4
PEPOCH 54321.0
GLEP_1 53219.0
GLPH_1 0.1
GLF0 1e-5
and I try and run, e.g.:
tempo2 -gr fake -f test.par -ndobs 1 -nobsd 1 -ha 12 -randha y -start 57722 -end 57991 -rms 0.001
the code Seg. Faults just before it should print out the glitch parameters. If I run this in gdb it shows that the problem happens on line 1612 of textOutput.C
in the printGlitch
function, and the error is:
psr=<error reading variable: value of type `pulsar' requires 3539200 bytes, which is more than max-value-size>
If I get rid of the including the glitch parameters from the par file this is not a problem.
I'm assuming this is some memory allocation issue, but can others reproduce it?
Comments (6)
-
reporter -
reporter Just to add, this problem seems to happen when calling the
dglep
function. If I comment out the calls to that function then I don't get the seg fault. -
I just checked in a fix for a bug in that same part of the code, so I expect that I've somehow introduced another bug. I will investigate right away and see if I can replicate and fix the error.
-
-
assigned issue to
This is a bug in the fake plugin. I fixed a similar issue in the PLK plugin recently. Should be fixed as of b122955, but likely also a similar bug in other plugins.
For future reference, the problem is that the plugins allocate arrays like:
double array[MAX_OBSN];
My naive understanding is that this tries to allocate memory on the stack, but there is not enough room and it causes future writes to this array to corrupt other parts of the memory. The solution is to allocate large arrays dynamically, i.e.
double* array = double*[MAX_OBSN]; // the code delete[] array;
Which does mean that the program needs to clean up it's memory, but it avoids writing junk over the memory and causing segfaults in future routines. For whatever reason the glitch printing routine is most sensitive to this.
As for why it suddenly appeared - I guess someone increased the default value of MAX_OBSN?
-
assigned issue to
-
reporter Thanks very much for the quick fix. I can confirm that this works for me too.
-
reporter - changed status to resolved
- Log in to comment