Printing of glitch parameters causes a SegFault

Issue #45 resolved
Matt Pitkin created an issue

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)

  1. Matt Pitkin 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.

  2. Michael Keith

    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.

  3. Michael Keith

    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?

  4. Log in to comment