Segfault during live capture under OS X about gr-iridium

[schneider42]

Thanks for the stack trace. I'm not sure why you are running into these issues. Maybe there is a bug in the code which does not surface under Linux.

Can you turn on debugging in burst_downmix_impl.cc on line 93, by putting a true in there (sorry, but the file does not respect the debug flag yet).

It will print a max_index= just before crashing. This should give an indication about what is going on.

[JosephRedfern]

@schneider42 Thanks. I've just re-compiled with that flag set, but won't have access to the HackRF until Monday. I'll try again then and let you know the output.

Oh, and I can rule out a HackRF hardware issue, as everything is working as expected under my Linux machine.

[JosephRedfern]

@schneider42 Got a chance to try running with the changed flag. The output can be seen here:

https://gist.github.com/JosephRedfern/255a60431e33c21b888745acb0908910

[schneider42]

The debug output does not contain output from the printf mentioned above. Did the program stop running right after outputting the first status line?

I also think you should try to capture a file using hackrf-transfer and then process that offline, to get reproducible results.

Command to capture a file: hackrf_transfer -r testfile.sc8 -f 1621800000 -a 1 -l 40 -g 20 -s 12000000

Command to process the file: iridium-extractor -c 1621800000 -r 12000000 -f hackrf --offline testfile.sc8 > output.bits

Try this a few times until you can (hopefully) crash the program. If you share the file I will also have a look.

[adecarolis]

I have the same problem and have performed the capture you requested.
Here are the stacktrace and the capture.

[schneider42]

Thanks. These files do not make my version segfault on Linux. We've spent a few hours on getting the thing to run at all under OS X. I hope to be able to reproduce this in the coming days.

[gyaresu]

FYI: Getting the same on a 'new' install for macOS Sierra on macports.

gyaresu on zaphod in ~/programming/gr-iridium/build(8d23h58m|master*) λ iridium-extractor -c 1621800000 -r 12000000 -f hackrf --offline /tmp/testfile.sc8 > /tmp/outfile.bits 1474584431 | i: 0/s | i_avg: 0/s | q: 0 | q_max: 0 | o: 0/s | ok: 0% | ok: 0/s | ok_avg: 0% | ok: 0 | ok_avg: 0/s | d: 0 [1] 55834 segmentation fault iridium-extractor -c 1621800000 -r 12000000 -f hackrf --offline >

[kgarrels]

This is happening in burst_downmix_impl.cc around line 401:

if max_index is 0, it will crash because you access the element max_index-1.

I added "+1", no more crashes.
I hope you find a better fix ;-)

  int max_index = x - d_magnitude_f+1;
  if(k_debug) {
    printf("max_index=%d\n", max_index);
  }
  // Interpolate the result of the FFT to get a finer resolution.
  // see http://www.dsprelated.com/dspbooks/sasp/Quadratic_Interpolation_Spectral_Peaks.html
  // TODO: The window should be Gaussian and the output should be put on a log scale
  float alpha = d_magnitude_f[(max_index - 1) % (d_cfo_est_fft_size * d_fft_over_size_facor)];
  float beta = d_magnitude_f[max_index];
  float gamma = d_magnitude_f[(max_index + 1) % (d_cfo_est_fft_size * d_fft_over_size_facor)];

[schneider42]

I think this is why I've added a % operation before using (max_index - 1). The intention is to wrap around if the index is out of bounds (the result of the FFT is also wrapping around at this point).

Turns out: -1 % x with x > 1 is actually -1 and not x - 1, as I obviously simply assumed. According to http://stackoverflow.com/questions/7594508/modulo-operator-with-negative-values this is how it is defined in C++11, and has been implemented like that for a long time already.

I'll change the operation so that it actually does what it is supposed to do...

Thanks a lot for spotting this!

[schneider42]

c6aff8a and 6695ddd should fix this.

The way the burst down mixing works (with the first FFT roughly centring the signal), max_index becomes 0 quite often. Apparently this does not surface under Linux...

With the new code, I can also decode one more frame inside my test capture :)

@kgarrels: Please give it a try

[kgarrels]

changes look good for me.