QT GUI Segmentation Fault

GNU Radio
1

Hi all,

I recently installed GNURadio on two laptops (installation via PYBOMBs)
and
everything has been running fine for a few weeks; but I’m suddenly
running
into issues with QT GUI on one of the laptops. I wasn’t sure what the
issue
was originally, but after narrowing it down I’m able to see the problem
with a simple flow graph:

signal source → throttle → QT GUI Sink

Starting with a blank slate in GRC and building the flow graph works
fine
on one device; but the same flow graph on the second laptop opens and
closes immediately with return code -11. If I run the python code
outside
of GRC, I get the segmentation fault.

I was looking for a solution and I came across bug 645 (
http://gnuradio.org/redmine/issues/645) that was resolved in 3.7.3, but
these laptops have 3.7.6 (git-133-gd814810) installed.

I noticed that the bug report mentions the avx volk kernel as the issue
and
both of my machines indicate that they’re using volk machine avx_64_mmx.
I
also ran volk_profile and changed “volk_32fc_32f_multiply_32fc a_avx
generic” to “volk_32fc_32f_multiply_32fc generic generic” as indicated
in
the bug report, but I still see the problem.

To be honest, I don’t really know how the volk library works and I’m not
sure what else I should try changing. If anybody has suggestions, it
would
be greatly appreciated.

Thanks in advance,

-Mike

2

Just a follow up on this - I was able to resolve the issue with the
following modifications in the volk_config file:

before: volk_32fc_32f_multiply_32fc a_avx generic
changed to: volk_32fc_32f_multiply_32fc generic generic

before: volk_32fc_deinterleave_64f_x2 a_avx u_avx
changed to: volk_32fc_deinterleave_64f_x2 generic u_avx

While I’m happy to have it working again, I don’t exactly know what this
modification actually does. If anyone with knowledge of the volk library
can give me a quick bit of info about what these modifications are
actually
doing and / or why this would resolve the segfault issue, it would ease
my
mind a bit.

Thanks,

-Mike

3

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

4

Hi Johnathan,

Thanks for the reply. I’m using Ubuntu 14.04 on a Dell XPS laptop with 8
cores. Results of the grep call are below:

model name : Intel(R) Core™ i7-2630QM CPU @ 2.00GHz
model name : Intel(R) Core™ i7-2630QM CPU @ 2.00GHz
model name : Intel(R) Core™ i7-2630QM CPU @ 2.00GHz
model name : Intel(R) Core™ i7-2630QM CPU @ 2.00GHz
model name : Intel(R) Core™ i7-2630QM CPU @ 2.00GHz
model name : Intel(R) Core™ i7-2630QM CPU @ 2.00GHz
model name : Intel(R) Core™ i7-2630QM CPU @ 2.00GHz
model name : Intel(R) Core™ i7-2630QM CPU @ 2.00GHz

I noticed that there are 12 other uses of a_avx in volk_config. Is it
likely that using any of the kernels with a_avx will cause a similar
issue?

-Mike

On Fri, Oct 31, 2014 at 2:19 PM, Johnathan C.
[email protected]

5

On Thu, Oct 30, 2014 at 4:07 PM, Michael R. [email protected] wrote:

While I’m happy to have it working again, I don’t exactly know what this
modification actually does. If anyone with knowledge of the volk library can
give me a quick bit of info about what these modifications are actually
doing and / or why this would resolve the segfault issue, it would ease my
mind a bit.

Thanks,

-Mike

Hi Mike,

So each VOLK kernel has several internal implementations that are
architecture specific (SSE, AVX, NEON, etc). A call to the VOLK
library looks like volk_32fc_32f_multiply_32fc(output_buffer,
input_buffer0, input_buffer1, number_of_points). Internally VOLK has a
dispatcher that uses the implementation that is “best” for your
machine. The “best” implementation is determined by running
volk_profile which runs all of the implementations available and write
the fastest one to volk_config. At run-time VOLK reads this file to
know which version of each kernel to actually run.

Can you tell me your processor model name and flags? A copy of
/proc/cpuinfo (just one of the processors) would be useful.

Nathan

6

Hi Nathan,

Thanks for the info. In case you didn’t see my previous reply, the
processors are all “Intel(R) Core™ i7-2630QM CPU @ 2.00GHz”

-Mike

On Fri, Oct 31, 2014 at 3:32 PM, West, Nathan
[email protected]

7

On Fri, Oct 31, 2014 at 4:21 PM, Michael R. [email protected] wrote:

Hi Nathan,

Thanks for the info. In case you didn’t see my previous reply, the
processors are all “Intel(R) Core™ i7-2630QM CPU @ 2.00GHz”

-Mike

Ok, I think I understand what’s going wrong here. We’re calling an
aligned
VOLK call directly inside the fft function of that block that works off
a
buffer that we created (properly aligned) and a buffer that FFTW
created.
FFTW doesn’t always ship packaged with AVX support, so the FFT buffers
are
only designed for SSE use – that is, only guaranteed to be 16-byte
aligned. AVX requires 32-byte alignment.

The fix is simply. Just remove the _a call from lines 268 and 276 (in
sink_c_impl.cc). I was thinking that both buffers would be guaranteed to
have the right alignment, so I skipped the volk dispatcher and called
directly into the aligned kernel. We might just have to ban use of
anything
but the dispatchers in GNU Radio code from now on.

I’m not in a place to fix this right now, so I just reopened issue #645
to
remind myself to do this when I can.

Tom