Typo in there.... count can never be less than 0. The other thing that I think makes sense is that we might need some history to scroll back to, but I don't think it's necessarily bounded how much history... Are you using an upstream block that provides time_est tags? Also, what parameters are you providing to the clock sync? number of filters/filter size is the most interesting parameter here, but others might be useful too.
Nathan On Wed, Dec 7, 2016 at 12:00 PM, West, Nathan <n...@ostatemail.okstate.edu> wrote: > Some sanity appears! > > From what I can tell, count is keeping track of how many input samples > have been processed, which can never be 0. My proposed fix would be to > clamp count to 0 somewhere after line 462, but it would be nice for someone > to confirm this makes sense. > > Nathan > > On Wed, Dec 7, 2016 at 10:18 AM, devin kelly <dwwke...@gmail.com> wrote: > >> I rebuilt GR with CMAKE_BUILD_TYPE=Debug. The al and ar vairables got >> optimized out, what's the compiler option to prevent that? >> >> I think I've found part of the problem: >> >> Looking here (on frame 2 in gdb): >> >> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/ >> lib/pfb_clock_sync_ccf_impl.cc#L465 >> >> This is the line where filter is called (which is where the segfault >> occurs): >> >> d_filters[d_filtnum]->filter(&in[count+d_out_idx]) >> >> From GDB I can see >> >> d_filtnum = 0 >> count = -67108696 >> d_out_idx = 0 >> >> (gdb) bt >> #0 0x00007fedd163e77f in volk_32fc_32f_dot_prod_32fc_generic >> (result=0x539eb40, input=0x7fed94b925a0, taps=0x53bb9a0, num_points=45) at >> /local_disk/spectrum_challenge_src/volk/kernels/volk/volk_ >> 32fc_32f_dot_prod_32fc.h:83 >> #1 0x00007fedbdedcc3f in gr::filter::kernel::fir_filter >> _ccf::filter(std::complex<float> const*) (this=0x53af290, >> input=input@entry=0x7fed94b925a0) at /local_disk/spectrum_challenge >> _src/gnuradio/gr-filter/lib/fir_filter.cc:232 >> #2 0x00007fedbe22e041 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*> >> >&) (this= >> 0x53a1800, noutput_items=256, ninput_items=..., input_items=..., >> output_items=std::vector of length 1, capacity 1 = {...}) >> at /local_disk/spectrum_challenge_src/gnuradio/gr-digital/lib/ >> pfb_clock_sync_ccf_impl.cc:465 >> #3 0x00007fedd1bbdd17 in gr::block_executor::run_one_iteration() >> (this=this@entry=0x7fedafffedb0) >> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio- >> runtime/lib/block_executor.cc:451 >> #4 0x00007fedd1bfc6aa in gr::tpb_thread_body::tpb_threa >> d_body(boost::shared_ptr<gr::block>, int) (this=0x7fedafffedb0, >> block=..., max_noutput_items=<optimized out>) >> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio- >> runtime/lib/tpb_thread_body.cc:122 >> #5 0x00007fedd1bf0ed1 in boost::detail::function::void_ >> function_obj_invoker0<gr::thread::thread_body_wrapper<gr::tpb_container>, >> void>::invoke(boost::detail::function::function_buffer&) >> (this=0x53ddc90, this=<optimized out>) >> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio- >> runtime/lib/scheduler_tpb.cc:44 >> #6 0x00007fedd1bf0ed1 in boost::detail::function::void_ >> function_obj_invoker0<gr::thread::thread_body_wrapper<gr::tpb_container>, >> void>::invoke(boost::detail::function::function_buffer&) (this=0x53ddc90) >> at /local_disk/spectrum_challenge_src/gnuradio/gnuradio- >> runtime/include/gnuradio/thread/thread_body_wrapper.h:51 >> #7 0x00007fedd1bf0ed1 in boost::detail::function::void_ >> function_obj_invoker0<gr::thread::thread_body_wrapper<gr::tpb_container>, >> void>::invoke(boost::detail::function::function_buffer&) >> (function_obj_ptr=...) >> at /usr/include/boost/function/function_template.hpp:153 >> #8 0x00007fedd1ba5050 in boost::detail::thread_data<boost::function0<void> >> >::run() (this=<optimized out>) >> at /usr/include/boost/function/function_template.hpp:767 >> #9 0x00007fedd1ba5050 in boost::detail::thread_data<boost::function0<void> >> >::run() (this=<optimized out>) >> at /usr/include/boost/thread/detail/thread.hpp:117 >> #10 0x00007fedd06a527a in thread_proxy () at >> /lib64/libboost_thread-mt.so.1.53.0 >> #11 0x00007fedec395dc5 in start_thread () at /lib64/libpthread.so.0 >> #12 0x00007fedeb9bb73d in clone () at /lib64/libc.so.6 >> (gdb) f 1 >> #1 0x00007fedbdedcc3f in gr::filter::kernel::fir_filter_ccf::filter >> (this=0x53af290, input=input@entry=0x7fed94b925a0) >> at /local_disk/spectrum_challenge_src/gnuradio/gr-filter/lib/ >> fir_filter.cc:232 >> 232 (d_ntaps+al)); >> (gdb) info locals >> ar = <optimized out> >> al = <optimized out> >> (gdb) print d_ntaps >> $1 = 45 >> (gdb) print al >> $2 = <optimized out> >> (gdb) print d_aligned_taps[al] >> value has been optimized out >> (gdb) print d_aligned_taps[0] >> >> >> >> $3 = (float *) 0x53bb9a0 >> (gdb) print d_aligned_taps[1] >> >> >> >> $4 = (float *) 0x53bbac0 >> (gdb) print input >> $5 = (const gr_complex *) 0x7fed94b925a0 >> (gdb) print *input >> Cannot access memory at address 0x7fed94b925a0 >> (gdb) print real(*input) >> No symbol "real" in current context. >> (gdb) print ar >> $6 = <optimized out> >> >> (gdb) f 2 >> #2 0x00007fedbe22e041 in gr::digital::pfb_clock_sync_ccf_impl::general_work >> (this=0x53a1800, noutput_items=256, >> ninput_items=..., input_items=..., output_items=std::vector of length >> 1, capacity 1 = {...}) >> at /local_disk/spectrum_challenge_src/gnuradio/gr-digital/lib/ >> pfb_clock_sync_ccf_impl.cc:465 >> 465 out[i+d_out_idx] = d_filters[d_filtnum]->filter(& >> in[count+d_out_idx]); >> (gdb) print d_filtnum >> $7 = 0 >> (gdb) print count >> $8 = -67108696 >> (gdb) print d_out_idx >> $9 = 0 >> (gdb) print in >> $10 = (gr_complex *) 0x7fedb4b92060 >> (gdb) print count+d_out_idx >> $11 = -67108696 >> (gdb) in[count+d_out_idx] >> Ambiguous command "in[count+d_out_idx]": . >> (gdb) print in[count+d_out_idx] >> Cannot access memory at address 0x7fed94b925a0 >> >> >> >> >> >> >> On Tue, Dec 6, 2016 at 2:04 PM, Marcus Müller <marcus.muel...@ettus.com> >> wrote: >> >>> Hi, >>> hm, you're right, the only way that can happen is if either the input or >>> the tap pointers are invalid; strange. >>> >>> Since the line in question, >>> 465 out[i+d_out_idx] = d_filters[d_filtnum]->filter(& >>> in[count+d_out_idx]); >>> in pfb_clock_sync_ccf.cc isn't all that suspicious, let's harass GDB for >>> a moment. >>> >>> 1. since you're in stack frame #0 by default, can you see whether you >>> can `print number` from the gdb shell? It's possible that GCC optimized >>> that variable away, so try `print bPtr`, too. >>> 2. From 1. we know whether this happens on the first loop iteration or a >>> subsequent one; that will show in which direction we'd look for bugs >>> 3. `frame 1` brings us into the context of the fir_filter_ccf::filter >>> function. `print al` and `print d_ntaps`, please! >>> 4. We're getting a bit fancy here with gdb, but whatever :) `print >>> d_aligned_taps[al]` >>> >>> Hope this gives us a push forward! >>> >>> Greetings, >>> Marcus >>> >>> >>> >>> On 12/06/2016 07:24 PM, devin kelly 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_32 >>> fc_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_threa >>> d_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_32 >>> fc_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 >>> >>> >>> The fault happens here: >>> >>> https://github.com/gnuradio/volk/blob/master/kernels/volk/vo >>> lk_32fc_32f_dot_prod_32fc.h#L83 >>> >>> >>> Since aPtr is just >>> >>> const float* aPtr = (float*)input; >>> >>> Maybe the issue is with pfb_clock_sync_ccf_impl? I'm not sure. >>> >>> Devin >>> >>> On Tue, Dec 6, 2016 at 1:06 PM, devin kelly <dwwke...@gmail.com> wrote: >>> >>>> It's a bit of both. The segfault usually happens on packet between >>>> packets 2 and 3 (I send one packet per second on my transmitter) but >>>> sometimes will happen a few packets later. It also always segfaults, I've >>>> gotten it to segfault about 20 times or so. >>>> >>>> On Tue, Dec 6, 2016 at 12:24 PM, West, Nathan < >>>> n...@ostatemail.okstate.edu> wrote: >>>> >>>>> Honestly, my money would be on GCC 4.8.5 being less buggy than 6.2, >>>>> but that's a separate topic. >>>>> >>>>> You can configure VOLK to not use this protokernel and there's some >>>>> documentation on how to do it here: http://gnuradio.org/doc/ >>>>> doxygen/volk_guide.html#volk_tuning >>>>> >>>>> This is fairly concerning though... are you able to consistently >>>>> trigger a segfault or is it a seemingly random event that you can't >>>>> trigger? >>>>> >>>>> On Tue, Dec 6, 2016 at 11:48 AM, devin kelly <dwwke...@gmail.com> >>>>> wrote: >>>>> >>>>>> OK, I tried a brand new GR/Volk install and still had the same >>>>>> problem. So no problem with re-linking Volk to GR. Could this be an >>>>>> issue >>>>>> with Volk on GCC 4.8.5? The newest GCC is 6.2 so 4.8.5 is pretty old, >>>>>> though the newest for Red Hat 7. Is there any way to reconfigure volk to >>>>>> not use volk_32fc_32f_dot_prod_32fc_a_avx? >>>>>> >>>>>> Here's volk-config-info: >>>>>> >>>>>> $ volk-config-info --all --prefix --cc --cflags --avail-machines >>>>>> --machine --alignment --malloc >>>>>> /local_disk/spectrum_challenge >>>>>> cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11) >>>>>> Copyright (C) 2015 Free Software Foundation, Inc. >>>>>> This is free software see the source for copying conditions. There >>>>>> is NO >>>>>> warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>>>>> PURPOSE. >>>>>> /usr/bin/cc::: -Wall >>>>>> /usr/bin/c++::: -Wall >>>>>> generic_orc:::GNU:::-g -Wall >>>>>> sse2_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 >>>>>> sse3_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 >>>>>> ssse3_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 >>>>>> -mssse3 >>>>>> sse4_a_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 >>>>>> -msse4a -mpopcnt >>>>>> sse4_1_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 >>>>>> -mssse3 -msse4.1 >>>>>> sse4_2_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 >>>>>> -mssse3 -msse4.1 -msse4.2 -mpopcnt >>>>>> avx_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 >>>>>> -mssse3 -msse4.1 -msse4.2 -mpopcnt -mavx >>>>>> avx2_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 >>>>>> -mssse3 -msse4.1 -msse4.2 -mpopcnt -mavx -mfma -mavx2 >>>>>> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc >>>>>> ;sse4_a_64_mmx_orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_6 >>>>>> 4_mmx_orc;avx2_64_mmx_orc; >>>>>> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc >>>>>> ;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_64_mmx_orc;avx2_64_mmx_orc; >>>>>> avx2_64_mmx_orc >>>>>> Alignment in bytes: 32 >>>>>> Used malloc implementation: posix_memalign >>>>>> >>>>>> >>>>>> Thanks again for any help, >>>>>> Devin >>>>>> >>>>>> >>>>>> On Fri, Dec 2, 2016 at 10:04 AM, Marcus Müller < >>>>>> marcus.muel...@ettus.com> wrote: >>>>>> >>>>>>> Oh, that's pretty interesting! Well, no misconfiguration should >>>>>>> segfault, so I'm a bit stumped at the moment. >>>>>>> >>>>>>> On 12/01/2016 06:14 PM, devin kelly wrote: >>>>>>> >>>>>>> Marcus, >>>>>>> >>>>>>> Thanks for taking the time. It is possible I re-installed a new >>>>>>> version of VOLK. I'll try a fresh build and see what that gets me. >>>>>>> >>>>>>> I also should have mentioned that the filter works OK for a while >>>>>>> then segfaults. A couple of packets always pass through the clock sync >>>>>>> block I'm using before I get the segfault. Finally, the segfault >>>>>>> occurs in >>>>>>> the polyphase clock sync block, do you think I could have mis-configured >>>>>>> the block in some way that will get me this error? I think the PF clock >>>>>>> sync block is pretty popular so if there's a bug in that block that's >>>>>>> causing this I'd be surprised. >>>>>>> >>>>>>> Devin >>>>>>> >>>>>>> On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller < >>>>>>> marcus.muel...@ettus.com> wrote: >>>>>>> >>>>>>>> Hi Devin, >>>>>>>> >>>>>>>> I don't think it's a kernel problem – all your calculations happen >>>>>>>> in userland, and the kernel has not much to say with respect to the >>>>>>>> instructions used. >>>>>>>> >>>>>>>> The most common reason for this kind of misbehaviour is in fact a >>>>>>>> problem with how the application (in this case, your GNU Radio >>>>>>>> application's block) calls into the library function (in this case the >>>>>>>> VOLK >>>>>>>> dot product). >>>>>>>> >>>>>>>> Is it possible that for some reason, GNU Radio used a previous >>>>>>>> version of VOLK when you linked it, and then the new version of VOLK >>>>>>>> was >>>>>>>> installed? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Marcus >>>>>>>> >>>>>>>> On 12/01/2016 05:23 PM, devin kelly wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I'm having a problem with the above VOLK function segfaulting. I >>>>>>>> don't think I'm passing any incorrect values to VOLK. My problem >>>>>>>> could be >>>>>>>> that I'm on RHEL7 with (obviously) an older kernel: >>>>>>>> >>>>>>>> $ uname -a >>>>>>>> Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 >>>>>>>> 04:54:55 EST 2016 x86_64 x86_64 x86_64 GNU/Linux >>>>>>>> >>>>>>>> I'm on VOLK 1.3 and GR 3.7.10.1. >>>>>>>> >>>>>>>> it segfaults here: >>>>>>>> https://github.com/gnuradio/volk/blob/maint/kernels/volk/vol >>>>>>>> k_32fc_32f_dot_prod_32fc.h#L119 >>>>>>>> It looks like aPtr (0x7fea5c3014c0) is somehow not valid. GR >>>>>>>> passes this pointer to VOLK so maybe it's a GR problem? >>>>>>>> >>>>>>>> I've copied the output of a GDB session and my CPU info below. >>>>>>>> >>>>>>>> Thanks for any help, >>>>>>>> Devin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Program terminated with signal 11, Segmentation fault. >>>>>>>> #0 0x00007fea7b1bd8b7 in _mm256_load_ps (__P=0x7fea5c3014c0) at >>>>>>>> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835 >>>>>>>> 835 return *(__m256 *)__P; >>>>>>>> Missing separate debuginfos, use: debuginfo-install >>>>>>>> python-2.7.5-48.el7.x86_64 >>>>>>>> (gdb) bt >>>>>>>> #0 0x00007fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx >>>>>>>> (__P=0x7fea5c3014c0) at /usr/lib/gcc/x86_64-redhat-lin >>>>>>>> ux/4.8.5/include/avxintrin.h:835 >>>>>>>> #1 0x00007fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx >>>>>>>> (result=0x3665160, input=0x7fea5c3014c0, taps=0x3671a00, >>>>>>>> num_points=47) at >>>>>>>> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_ >>>>>>>> dot_prod_32fc.h:119 >>>>>>>> #2 0x00007fea6661d88f in gr::filter::kernel::fir_filter >>>>>>>> _ccf::filter(std::complex<float> const*) () at >>>>>>>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-filter-3.7.10.1.so.0.0.0 >>>>>>>> #3 0x00007fea66c01d01 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/gr_3.7.10.1/lib64/libgnuradio-digital-3.7.10.1.s >>>>>>>> o.0.0.0 >>>>>>>> #4 0x00007fea7b73fe10 in gr::block_executor::run_one_iteration() >>>>>>>> () at /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.s >>>>>>>> o.0.0.0 >>>>>>>> #5 0x00007fea7b781120 in gr::tpb_thread_body::tpb_threa >>>>>>>> d_body(boost::shared_ptr<gr::block>, int) () at >>>>>>>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0 >>>>>>>> #6 0x00007fea7b774821 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.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0 >>>>>>>> #7 0x00007fea7b725ef0 in >>>>>>>> boost::detail::thread_data<boost::function0<void> >>>>>>>> >::run() () at /local_disk/gr_3.7.10.1/lib64/ >>>>>>>> libgnuradio-runtime-3.7.10.1.so.0.0.0 >>>>>>>> #8 0x00007fea7a22427a in thread_proxy () at >>>>>>>> /lib64/libboost_thread-mt.so.1.53.0 >>>>>>>> #9 0x00007fea960f3dc5 in start_thread () at /lib64/libpthread.so.0 >>>>>>>> #10 0x00007fea9571973d in clone () at /lib64/libc.so.6 >>>>>>>> (gdb) print __P >>>>>>>> $1 = (const float *) 0x7fea5c3014c0 >>>>>>>> (gdb) print *__P >>>>>>>> Cannot access memory at address 0x7fea5c3014c0 >>>>>>>> (gdb) print *(__m256 *)__P >>>>>>>> Cannot access memory at address 0x7fea5c3014c0 >>>>>>>> (gdb) f 1 >>>>>>>> #1 volk_32fc_32f_dot_prod_32fc_a_avx (result=0x3665160, >>>>>>>> input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at >>>>>>>> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_ >>>>>>>> dot_prod_32fc.h:119 >>>>>>>> 119 a0Val = _mm256_load_ps(aPtr); >>>>>>>> (gdb) info locals >>>>>>>> number = 0 >>>>>>>> sixteenthPoints = 2 >>>>>>>> res = {-1.30492652e+29, 0.0779444203} >>>>>>>> realpt = 0x7fea57ffde50 >>>>>>>> imagpt = 0x7fea57ffde54 >>>>>>>> aPtr = 0x7fea5c3014c0 >>>>>>>> bPtr = 0x3671a00 >>>>>>>> a0Val = {-0.656753004, -0.658071458, -0.760932922, -0.762304127, >>>>>>>> -0.869615495, -0.869560063, -0.887507021, -0.885902643} >>>>>>>> a1Val = {-0.744178772, -0.742508531, -0.437728733, -0.437706977, >>>>>>>> -0.0328192525, -0.0346645005, 0.376206338, 0.374125361} >>>>>>>> a2Val = {0.711783648, 0.711464763, 0.931477308, 0.933318734, >>>>>>>> 1.01744843, 1.01973152, 0.954917312, 0.955377996} >>>>>>>> a3Val = {0.734342158, 0.732418418, 0.374049634, 0.371605545, >>>>>>>> -0.0585254543, -0.0588675328, -0.461206883, -0.458686352} >>>>>>>> b0Val = {0.0023738991, 0.0023738991, -0.00534401694, >>>>>>>> -0.00534401694, 0.00242348039, 0.00242348039, 0.00727195293, >>>>>>>> 0.00727195293} >>>>>>>> b1Val = {-0.0158917159, -0.0158917159, 0.00614725193, >>>>>>>> 0.00614725193, 0.0485430211, 0.0485430211, -0.22138992, -0.22138992} >>>>>>>> b2Val = {0, 0, 0.22138992, 0.22138992, -0.0485430211, >>>>>>>> -0.0485430211, -0.00614725193, -0.00614725193} >>>>>>>> b3Val = {0.0158917159, 0.0158917159, -0.00727195293, >>>>>>>> -0.00727195293, -0.00242348039, -0.00242348039, 0.00534401694, >>>>>>>> 0.00534401694} >>>>>>>> x0Val = {0.0023738991, -0.00534401694, 0.00242348039, >>>>>>>> 0.00727195293, -0.0158917159, 0.00614725193, 0.0485430211, -0.22138992} >>>>>>>> x1Val = {0, 0.22138992, -0.0485430211, -0.00614725193, >>>>>>>> 0.0158917159, -0.00727195293, -0.00242348039, 0.00534401694} >>>>>>>> x0loVal = {0.0023738991, 0.0023738991, -0.00534401694, >>>>>>>> -0.00534401694, -0.0158917159, -0.0158917159, 0.00614725193, >>>>>>>> 0.00614725193} >>>>>>>> x0hiVal = {0.00242348039, 0.00242348039, 0.00727195293, >>>>>>>> 0.00727195293, 0.0485430211, 0.0485430211, -0.22138992, -0.22138992} >>>>>>>> x1loVal = {0, 0, 0.22138992, 0.22138992, 0.0158917159, >>>>>>>> 0.0158917159, -0.00727195293, -0.00727195293} >>>>>>>> x1hiVal = {-0.0485430211, -0.0485430211, -0.00614725193, >>>>>>>> -0.00614725193, -0.00242348039, -0.00242348039, 0.00534401694, >>>>>>>> 0.00534401694} >>>>>>>> c0Val = {-0.00155906542, -0.00156219525, 0.00406643841, >>>>>>>> 0.00407376606, -0.00210749614, -0.0021073618, -0.00645390945, >>>>>>>> -0.0064422423} >>>>>>>> c1Val = {0.0118262777, 0.011799735, -0.00269082887, -0.00269069499, >>>>>>>> -0.00159314566, -0.00168271956, -0.0832882896, -0.082827583} >>>>>>>> c2Val = {0, 0, 0.206219688, 0.206627354, -0.0493900217, >>>>>>>> -0.0495008491, -0.00587011734, -0.00587294903} >>>>>>>> c3Val = {0.0116699571, 0.0116393855, -0.00272007124, >>>>>>>> -0.00270229811, 0.000141835291, 0.000142664314, -0.00246469746, >>>>>>>> -0.00245122775} >>>>>>>> dotProdVal0 = {0, 0, 0, 0, 0, 0, 0, 0} >>>>>>>> dotProdVal1 = {0, 0, 0, 0, 0, 0, 0, 0} >>>>>>>> dotProdVal2 = {0, 0, 0, 0, 0, 0, 0, 0} >>>>>>>> dotProdVal3 = {0, 0, 0, 0, 0, 0, 0, 0} >>>>>>>> dotProductVector = {0.0218032673, 0.0217418969, 0.204074427, >>>>>>>> 0.204509094, -0.0519821495, -0.0521854945, -0.0983558819, -0.097870864} >>>>>>>> (gdb) print *aPtr >>>>>>>> Cannot access memory at address 0x7fea5c3014c0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> $ lscpu >>>>>>>> Architecture: x86_64 >>>>>>>> CPU op-mode(s): 32-bit, 64-bit >>>>>>>> Byte Order: Little Endian >>>>>>>> CPU(s): 4 >>>>>>>> On-line CPU(s) list: 0-3 >>>>>>>> Thread(s) per core: 2 >>>>>>>> Core(s) per socket: 2 >>>>>>>> Socket(s): 1 >>>>>>>> NUMA node(s): 1 >>>>>>>> Vendor ID: GenuineIntel >>>>>>>> CPU family: 6 >>>>>>>> Model: 61 >>>>>>>> Model name: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz >>>>>>>> Stepping: 4 >>>>>>>> CPU MHz: 2038.664 >>>>>>>> BogoMIPS: 5187.61 >>>>>>>> Virtualization: VT-x >>>>>>>> L1d cache: 32K >>>>>>>> L1i cache: 32K >>>>>>>> L2 cache: 256K >>>>>>>> L3 cache: 4096K >>>>>>>> NUMA node0 CPU(s): 0-3 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Discuss-gnuradio mailing >>>>>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>>> >>>>>>>> _______________________________________________ Discuss-gnuradio >>>>>>>> mailing list Discuss-gnuradio@gnu.org >>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Discuss-gnuradio mailing >>>>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>> >>>>>>> _______________________________________________ Discuss-gnuradio >>>>>>> mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/ >>>>>>> listinfo/discuss-gnuradio >>>>>> >>>>>> _______________________________________________ Discuss-gnuradio >>>>>> mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/ >>>>>> listinfo/discuss-gnuradio >>>>> >>>>> _______________________________________________ >>> Discuss-gnuradio mailing >>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
