On Tue, Dec 6, 2016 at 1:24 PM, devin kelly <dwwke...@gmail.com> wrote:
> I changed my volk_config like so
>
> volk_32fc_32f_dot_prod_32fc generic generic
>
> And I still get a segfault:
>
> gdb python core.8035
>
> .....
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007f116379277f in volk_32fc_32f_dot_prod_32fc_generic
> (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860,
> num_points=45) at /local_disk/spectrum_challenge_src/volk/kernels/
> volk/volk_32fc_32f_dot_prod_32fc.h:83
> 83 *realpt += ((*aPtr++) * (*bPtr));
> Missing separate debuginfos, use: debuginfo-install
> python-2.7.5-48.el7.x86_64
> (gdb) bt
> #0 0x00007f116379277f in volk_32fc_32f_dot_prod_32fc_generic
> (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at
> /local_disk/spectrum_challenge_src/volk/kernels/
> volk/volk_32fc_32f_dot_prod_32fc.h:83
> #1 0x00007f114ffff74f in
> gr::filter::kernel::fir_filter_ccf::filter(std::complex<float>
> const*) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> filter-3.7.10.1.so.0.0.0
> #2 0x00007f1150356b41 in
> gr::digital::pfb_clock_sync_ccf_impl::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/spectrum_challenge/lib64/libgnuradio-
> digital-3.7.10.1.so.0.0.0
> #3 0x00007f1163d14d80 in gr::block_executor::run_one_iteration() ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #4 0x00007f1163d56090 in gr::tpb_thread_body::tpb_
> thread_body(boost::shared_ptr<gr::block>, int) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #5 0x00007f1163d49791 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/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #6 0x00007f1163cfae60 in boost::detail::thread_data<boost::function0<void>
> >::run() ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #7 0x00007f11627f927a in thread_proxy () at /lib64/libboost_thread-mt.so.
> 1.53.0
> #8 0x00007f117e4d8dc5 in start_thread () at /lib64/libpthread.so.0
> #9 0x00007f117dafe73d in clone () at /lib64/libc.so.6
> (gdb) f 0
> #0 0x00007f116379277f in volk_32fc_32f_dot_prod_32fc_generic
> (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at
> /local_disk/spectrum_challenge_src/volk/kernels/
> volk/volk_32fc_32f_dot_prod_32fc.h:83
> 83 *realpt += ((*aPtr++) * (*bPtr));
> (gdb) info locals
> res = {0, 0}
> realpt = 0x7f114680f570
> imagpt = 0x7f114680f574
> aPtr = 0x7f1126cac684
> bPtr = 0x56ea860
> number = 0
> (gdb) print realpt
> $1 = (float *) 0x7f114680f570
> (gdb) print *realpt
> $2 = 0
> (gdb) print aPtr
> $3 = (const float *) 0x7f1126cac684
> (gdb) print *aPtr
> Cannot access memory at address 0x7f1126cac684
> (gdb) print bPtr
> $4 = (const float *) 0x56ea860
> (gdb) print *bPtr
> $5 = 0.000685208186
>
If I'm doing the arithmetic correctly aPtr is pointing to memory that the
caller claimed was valid and we aren't doing anything so funny here that I
would expect a segfault. It does appear that this might be a bug you are
triggering, but the question is why.
What are your parameters for the clock sync?
Are you able to get a small snapshot of data that will consistently cause
this? For example, file source -> pfb clock sync -> null sink which will
consistently fail.
Does this occur only with the one modem/data pattern+channel you're working
on?
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
