[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Unhandled exception after upgrading gnuradio- bac

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Unhandled exception after upgrading gnuradio- backtrace included
Date: Thu, 8 Mar 2012 20:24:25 -0500

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

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.



Attachment: fft_malloc.diff
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]