On Fri, May 29, 2015 at 4:33 PM, <[email protected]> wrote:
> I've been trying out the (bleeding edge) corr_est() code and the > test_corr_est.grc sometimes segvs. Not repeatable, won't crash under gdb > :-) From a core file, it's crashing loading the first element of aVector in > volk_32fc_x2_multiply_32fc_a_avx > instruction is vmovaps (%eax),%ymm1 where eax is 0x8b8b590. > > My CPU supports the 256bit AVX instructions, and I believe such data needs > to be 256bit=32 byte aligned. EAX here isn't. Looking at the backtrace, > it's crashing in fft_filter_ccc::filter, where the d_fwdfft is generated > from fft::fft_complex > > In turn this creates d_inbuf by calling fftwf_malloc. I believe this only > guarantees 16 byte alignment. (I'm on fftw3.3.4, on a 32 bit Linux 3.18.1, > CPU Intel i5-3470) > > As we move to use volk and the fast SIMD, should the code in fft.cc (and > perhaps other places) move to using a volk memory allocator to get the > right alignment, rather than fftwf_malloc? > > I'm on gentoo, so I could fix the source to fftwf_malloc to return 32 byte > aligned, but that's not a general solution. > > I'm not sure how I should report this issue, please pass on my report if > there's a better place to discuss such things > -- > G8SQH > <[email protected]> > Yes, this is absolutely a problem with using the fftw_malloc functions. Unless told, FFTW doesn't build AVX support, which means that it can return vectors that are not AVX-aligned, and the code is calling the _a kernel and so requires it to be appropriately aligned. Can you change and fftw_malloc'd arrays used in volk calls to volk_malloc and a) make sure that works and b) submit a patch with where you're running into this? I thought we had fixed these already (also, what version are you running?). Tom
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
