Forum: GNU Radio segfault: __convert_sc16_item16_usrp1_1_fc32_2_PRIORITY_GENERAL::operator()

Okay, so was in zombie mode when I typed the command, but certainly was 
not expecting to get a segmentation fault.


The failing command was
 /usr/bin/python /usr/local/bin/uhd_fft --spec 'A:0 B:0' -f 924e6

Things worked fine with --spec 'A:0'. Below is the seg fault, reported 
in case there's anything serious behind it...

This is from uhd git as of Feb. 2.

Best

Max
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Core was generated by `/usr/bin/python /usr/local/bin/uhd_fft --spec A:0 
B:0 -f 924e6'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f43783f3276 in 
__convert_sc16_item16_usrp1_1_fc32_2_PRIORITY_GENERAL::operator()(uhd::ref_vector<void 
const*> const&, uhd::ref_vector<void*> const&, unsigned long) () from 
/usr/local/lib/libuhd.so.003

(gdb) i stack
#0 0x00007f43783f3276 in 
__convert_sc16_item16_usrp1_1_fc32_2_PRIORITY_GENERAL::operator()(uhd::ref_vector<void 
const*> const&, uhd::ref_vector<void*> const&, unsigned long) () from 
/usr/local/lib/libuhd.so.003
#1 0x00007f43785ac2ac in 
usrp1_recv_packet_streamer::recv(uhd::ref_vector<void*> const&, unsigned 
long, uhd::rx_metadata_t&, double, bool) () from 
/usr/local/lib/libuhd.so.003
#2 0x00007f43789c1718 in uhd_usrp_source_impl::work(int, 
std::vector<void const*, std::allocator<void const*> >&, 
std::vector<void*, std::allocator<void*> >&) () from 
/usr/local/lib/libgnuradio-uhd-3.6.3git.so.0.0.0
#3 0x00007f437e846754 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*> 
>&) () from /usr/local/lib/libgnuradio-core-3.6.3git.so.0.0.0
#4 0x00007f437e8284d6 in gr_block_executor::run_one_iteration() () from 
/usr/local/lib/libgnuradio-core-3.6.3git.so.0.0.0
#5 0x00007f437e849bf4 in 
gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr<gr_block>, int) 
()
 from /usr/local/lib/libgnuradio-core-3.6.3git.so.0.0.0
#6 0x00007f437e84319f 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.3git.so.0.0.0
#7 0x00007f437e5782a5 in 
boost::detail::thread_data<boost::function0<void> >::run() () from 
/usr/local/lib/libgruel-3.6.3git.so.0.0.0
#8 0x00007f437dab2230 in thread_proxy () from 
/usr/lib/libboost_thread.so.1.42.0
#9 0x00007f43809ff971 in start_thread () from /lib/libpthread.so.0
#10 0x00007f437f8db92d in clone () from /lib/libc.so.6
#11 0x0000000000000000 in ?? ()

On 03/07/2013 01:34 PM, ikjtel wrote:
> Okay, so was in zombie mode when I typed the command, but certainly was not 
expecting to get a segmentation fault.
>
>
> The failing command was
>    /usr/bin/python /usr/local/bin/uhd_fft --spec 'A:0 B:0' -f 924e6
>
> Things worked fine with --spec 'A:0'.  Below is the seg fault, reported in case 
there's anything serious behind it...
>
> This is from uhd git as of Feb. 2.usrp3_b200_fix
>

The uhd fft only displays one channel. You will have to keep the
frontend specification to a single frontend for this app.

It looks like error checking didnt catch this, but there is a mismatch
in the number of source outputs for the gnuradio block and the number of
channels setup on the frontend. Something was off by a factor of two,
and bad memory was accessed.

-josh