[Top][All Lists]

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

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

From: West, Nathan
Subject: Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma
Date: Mon, 7 Mar 2016 22:18:08 -0500

On Mon, Mar 7, 2016 at 2:32 PM, devin kelly <address@hidden> wrote:

I've built a flowgraph (grc, python attached) that usually (but not always) produces a segfaults in volk_32fc_x2_multiply_32fc_a_avx2_fma.  The segfault occurs in the FFT filter in correlation estimator block.  I'm not sure if it's the Volk code that's causing the segfault or the GR code calling it or what I'm putting into GR.  I've got a back trace below if that helps. 

Also, at the tag gate in my flowgraph I would usually have a USRP transmitter and a USRP receiver in a before the Correlation Estimate in a separate flowgraph but since I can re-create the segfault in the flowgraph I simplified.

I'm using GR 3.7.9, Volk 1.2.1 and UHD 3.9.2 (though I don't call any UHD code here).

Thanks for any help,

$ gdb /usr/bin/python core.13408
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /usr/bin/python2.7...Reading symbols from /usr/bin/python2.7...(no debugging symbols found)...done.
(no debugging symbols found)...done.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `python2 ./segfault_test.py'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f11a4d064c0 in volk_32fc_x2_multiply_32fc_a_avx2_fma () from /local_disk/gr_3.7.9/lib/libvolk.so.1.2.1
Missing separate debuginfos, use: debuginfo-install python-2.7.5-34.el7.x86_64
(gdb) bt
#0  0x00007f11a4d064c0 in volk_32fc_x2_multiply_32fc_a_avx2_fma () at /local_disk/gr_3.7.9/lib/libvolk.so.1.2.1
#1  0x00007f119c1d0006 in gr::filter::kernel::fft_filter_ccc::filter(int, std::complex<float> const*, std::complex<float>*) ()
    at /local_disk/gr_3.7.9/lib64/libgnuradio-filter-3.7.9.so.0.0.0
#2  0x00007f119c4d724f in gr::digital::corr_est_cc_impl::work(int, std::vector<void const*, std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&) () at /local_disk/gr_3.7.9/lib64/libgnuradio-digital-3.7.9.so.0.0.0
#3  0x00007f11a52b1f57 in gr::sync_block::general_work(int, std::vector<int, std::allocator<int> >&, std::vector<void const*, std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&) () at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
#4  0x00007f11a527a6bd in gr::block_executor::run_one_iteration() () at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
#5  0x00007f11a52baf60 in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr<gr::block>, int) ()
    at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
#6  0x00007f11a52aebc1 in boost::detail::function::void_function_obj_invoker0<gr::thread::thread_body_wrapper<gr::tpb_container>, void>::invoke(boost::detail::function::function_buffer&) () at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
#7  0x00007f11a5260910 in boost::detail::thread_data<boost::function0<void> >::run() ()
    at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
#8  0x00007f11a40b824a in thread_proxy () at /lib64/libboost_thread-mt.so.1.53.0
#9  0x00007f11bfa38dc5 in start_thread () at /lib64/libpthread.so.0
#10 0x00007f11bf05d28d in clone () at /lib64/libc.so.6

Discuss-gnuradio mailing list

I couldn't reproduce this on my machine with avx2. Your GRC flowgraph didn't draw anything, so I replaced your FG with random source(0,255) -> const. modulator -> correlation est -> sinks.

I'm wondering if a bad vector length is getting passed in by accident. Can you get the parameters to the VOLK call when it crashes? If you're not familiar with gdb do something like the following:
gdb> f 0
gdb> info variables

reply via email to

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