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_ > thread_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_ >> 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_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_ >> 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 >> >> >> 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
