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_ > 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 > > > The fault happens here: > > https://github.com/gnuradio/volk/blob/master/kernels/volk/ > volk_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
