[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] I thought we had squashed this one
From: |
Tom Rondeau |
Subject: |
Re: [Discuss-gnuradio] I thought we had squashed this one |
Date: |
Wed, 6 Jun 2012 21:46:31 -0400 |
On Tue, Jun 5, 2012 at 11:45 PM, Marcus D. Leech <address@hidden> wrote:
> Got a core dump this evening from this evenings GIT build. On a Fedora
> 12 machine (I know, horbly obsolete),
> on a Centrino M CPU:
We did squash this bug. Why you gotta keep bringing up the past?
What version of FFTW is on that machine? The block should be calling
into fftw_malloc to get aligned arrays for the taps and the in/out
buffers are from the fftw object, anyways, so they are aligned. So
there's nothing that should be producing anything unaligned unless
FFTW isn't working like I think it should be working.
Tom
> #0 0x003bb409 in volk_32fc_x2_multiply_32fc_a_sse3 ()
> from /usr/local/lib/libvolk.so.0.0.0
> #1 0x00396415 in get_volk_32fc_x2_multiply_32fc_a ()
> from /usr/local/lib/libvolk.so.0.0.0
> #2 0x0096b7e7 in gri_fft_filter_ccc_generic::filter(int,
> std::complex<float> const*, std::complex<float>*) ()
> from /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0
> #3 0x00972a5b in gr_fft_filter_ccc::work(int, std::vector<void const*,
> std::allocator<void const*> >&, std::vector<void*, std::allocator<void*>
>>&) ()
> from /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0
> #4 0x00942187 in gr_sync_decimator::general_work(int, std::vector<int,
> std::allocator<int> >&, std::vector<void const*, std::allocator<void
> const*> >&, std::vector<void*, std::allocator<void*> >&) ()
> from /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0
> #5 0x00929455 in gr_block_executor::run_one_iteration() ()
> from /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0
> #6 0x00944bb3 in
> gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr<gr_block>, int)
> () from /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0
> #7 0x0093eecc in
> boost::detail::function::void_function_obj_invoker0<gruel::thread_body_wrapper<tpb_container>,
> void>::invoke(boost::detail::function::function_buffer&) () from
> /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0
> #8 0x0031084c in boost::function0<void>::operator()() const ()
> from /usr/local/lib/libgruel-3.6.1git.so.0.0.0
>
> Here's /proc/cpuinfo
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 14
> model name : Genuine Intel(R) CPU T2400 @ 1.83GHz
> stepping : 8
> cpu MHz : 1833.000
> cache size : 2048 KB
> physical id : 0
> siblings : 2
> core id : 0
> cpu cores : 2
> apicid : 0
> initial apicid : 0
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov
> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc
> arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm
> bogomips : 3657.43
> clflush size : 64
> cache_alignment : 64
> address sizes : 32 bits physical, 32 bits virtual
> power management:
>
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 6
> model : 14
> model name : Genuine Intel(R) CPU T2400 @ 1.83GHz
> stepping : 8
> cpu MHz : 1833.000
> cache size : 2048 KB
> physical id : 0
> siblings : 2
> core id : 1
> cpu cores : 2
> apicid : 1
> initial apicid : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov
> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc
> arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm
> bogomips : 3657.52
> clflush size : 64
> cache_alignment : 64
> address sizes : 32 bits physical, 32 bits virtual
> power management:
>
>
> Seems to have been provoked by replacing a regular FIR filter with an
> FFT filter (or rather, replacing
> 3 FIR filters with 3 FFT filters with the same "shape" as the FIR
> filters).
>
> Curiously enough, on Ubuntu 12.04 on *exactly the same hardware*, I
> don't have this problem, even
> with this evening's build.
>
>
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio