Re: [Discuss-gnuradio] Unhandled exception after upgrading gnuradio- backtrace included

[Tom Rondeau]

Ok, I have a branch 'volk_32bit_fixes' published at:

git://github.com/trondeau/gnuradio.git

This should fix the fft_filter issue and another issue in one of the volk convert functions (that is not used in GNU Radio but was failing anyway).

I'm still seeing the 32fc_x2_dot_product_32fc failure. It looks like this is in the SSE_32 proto-kernel. I'm seeing if we can get a quick fix for it. This is the same problem Martin was seeing. If we can't get a fix for it, I'm going to temporarily disable it until we get it fixed.

Tom

On Thu, Mar 8, 2012 at 8:24 PM, Tom Rondeau <address@hidden> wrote:

On Thu, Mar 8, 2012 at 2:35 PM, Marcus D. Leech <address@hidden> wrote:

On 08/03/12 02:25 PM, Tom Rondeau wrote:
>
> That still might be indicative of the problem, though, that the flags
> are being read incorrectly by the proc system. Very strange, that.
>
> Marcus, if you would, change the volk kernel from the aligned (_a) to
> the unaligned one (_u) and see what that does. In the FFT, since it's
> an FFTW buffer, it _should_ be aligned, but this will let us know.
>
> Tom
>

Ok, changed from the "_a" to the "_u" variant in
gri_fft_filter_{ccc,fff}, and voila!   It now works!

--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

Thanks to Marcus' help, I figured out the error here was due to a very silly assumption that I had made regarding our own array for the Fourier taps. Apparently, this is always handled "correctly" (for Volk's definition of correct) on 64-bit machines but not 32-bit ones.

Attached is a patch that uses fftw_malloc to create an array to store the taps in. I created some helper functions in gri_fft to abstract the specific use of fftw in the filter code itself like we've done with the rest of fftw's invocation.

Please try this out and let me know. I've only verified it on a 32-bit VM, so I just want to make sure there's nothing I'm missing (although it was failing previously as expected, so I think this works).

There are still a couple of other 32-bit issues that I'm seeing in other blocks. I'll look into those next.

Thanks,
Tom