Hello!
I am attempting to make a histogram of the output of FFT’s from a USURP source. I am in the process of writing this block to take in a large amount of fft’s and then process the data and write to file. I want to take an fft of length vec_len and then take vec_len amount of those, go down the columns of fft’s and assign it to an output in my OOT. Ideally, “vec_len” is going to be very large, on the order of 4096 or even more. To make sure I am getting a large enough buffer for my OOT, I have set the min output buffer to vec_len*vec_len+1. My OOT and grc program worked great for any vec_len of 512 and under. Everything went as planned. However, when I stepped vec_len up to 1024, the program throws a segmentation fault. Anything larger than 1024 throws the segmentation fault.
To find the problem, I used gdb, but that didn’t help much, as I know it’s a segmentation fault, and it is either in my block or in the log10 block.
Here is what I have done for my own debugging:
I have completely removed my OOT block from the program, and it still throws a segfault at the log10 block with the set output buffer.
I have increased the stack size using ulimit -s and ulimit -H to unlimited.
I have tried it with a noise source and a limeSDR to see If it was my source, still throws segfault at 1024.
If I set the min output buffer to 0, everything works dandy (without my OOT, however, as I need the large buffer size)
So I suppose my first question is, is there a maximum “min output buffer”? What else can I try to relieve these segfaults? I understand the latency that can and probably will occur with such a large buffer size, however for my application, it should not be too big of a problem.
I am running gnuradio 3.7.11.1 on 64bit Ubuntu. I understand this is not the newest version, however I am having the same issue on another computer with 3.8.
I have attached my grc file, python file, and core dump that I am receiving from the segfaults.
I appreciate any help that can be given, thank you!!
Josh