Hey, I managed to find a solution. So it really was a bug in GNU Radio 3.8. This issue proposes a workaround by clearing the stream channels variable in the uhd block (https://github.com/gnuradio/gnuradio/issues/2789). There is also an approved PR with a bugfix (https://github.com/gnuradio/gnuradio/pull/2823). Thus, it should be merged soon.
Alex ---------- Forwarded message --------- Von: Alexander W <[email protected]> Date: Di., 29. Okt. 2019 um 14:33 Uhr Subject: Re: [USRP-users] [usrp-users] E320 Multi TX Stream Operation in GR 3.8 stops during configuration of the USRP sink To: Sam Reiter <[email protected]> Hi Sam, I tested it with GNU Radio 3.7 and that worked (GNU Radio Companion 3.7.13.5, UHD 3.14.1.1-0-g0347a6d8). So it seems to be an issue with 3.8. I ran a minimum python script with GNU Radio 3.8 to get more information about the fault. Python3 script: from gnuradio import uhd sink=uhd.usrp_sink(",".join(('addr=192.168.10.2', "")),uhd.stream_args(cpu_format="fc32",args=",channels=[],),",)) sink.set_subdev_spec('A:0 A:1', 0) sink.set_center_freq(2e9, 0) sink.set_normalized_gain(0.5, 0) sink.set_antenna('TX/RX', 0) sink.set_center_freq(2e9, 1) Output with gdb: Thread 1 "python3" received signal SIGSEGV, Segmentation fault. std::__cxx11::list<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_M_assign_dispatch<std::_List_const_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > (__last2= {first = <error reading variable: Cannot create a lazy string with address 0x0, and a non-zero length.>, second = "\001\000"}, __first2= {first = <error reading variable: Cannot create a lazy string with address 0x0, and a non-zero length.>, second = "\001\000"}, this=0xc1f418) at /usr/include/c++/7/bits/list.tcc:317 317 erase(__first1, __last1); (gdb) backtrace #0 std::__cxx11::list<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_M_assign_dispatch<std::_List_const_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > (__last2= {first = <error reading variable: Cannot create a lazy string with address 0x0, and a non-zero length.>, second = "\001\000"}, __first2= {first = <error reading variable: Cannot create a lazy string with address 0x0, and a non-zero length.>, second = "\001\000"}, this=0xc1f418) at /usr/include/c++/7/bits/list.tcc:317 #1 std::__cxx11::list<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::operator= ( __x=empty std::__cxx11::list, this=0xc1f418) at /usr/include/c++/7/bits/list.tcc:285 #2 uhd::dict<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::operator= (this=<optimized out>) at /home/user/pybombs_gnuradio/include/uhd/types/dict.hpp:20 #3 uhd::device_addr_t::operator= (this=<optimized out>) at /home/user/pybombs_gnuradio/include/uhd/types/device_addr.hpp:38 #4 uhd::tune_request_t::operator= (this=<optimized out>) at /home/user/pybombs_gnuradio/include/uhd/types/tune_request.hpp:25 #5 gr::uhd::usrp_sink_impl::set_center_freq (this=0xb4c370, tune_request=..., chan=1) at /home/user/pybombs_gnuradio/src/gnuradio/gr-uhd/lib/usrp_sink_impl.cc:99 #6 0x00007ffff5cf1ff0 in gr::uhd::usrp_block::set_center_freq (chan=1, freq=<optimized out>, this=0xb4c510) at /home/user/pybombs_gnuradio/src/gnuradio/gr-uhd/lib/../include/gnuradio/uhd/usrp_block.h:134 #7 _wrap_usrp_sink_sptr_set_center_freq__SWIG_1 (args=args@entry=0x7ffff6161900) at /home/user/pybombs_gnuradio/src/gnuradio/build/gr-uhd/swig/CMakeFiles/uhd_swig.dir/uhd_swigPYTHON_wrap.cxx:42327 #8 0x00007ffff5cf9536 in _wrap_usrp_sink_sptr_set_center_freq (self=<optimized out>, args=0x7ffff6161900) at /home/user/pybombs_gnuradio/src/gnuradio/build/gr-uhd/swig/CMakeFiles/uhd_swig.dir/uhd_swigPYTHON_wrap.cxx:42397 Thanks for your help! Alex Am Do., 24. Okt. 2019 um 20:19 Uhr schrieb Sam Reiter <[email protected] >: > Alex, > > I suspect this is something specific to GNU Radio 3.8, but it's not > something I've seen up to this point. To help narrow down the problem, > could you run your test flowchart on GNU Radio 3.7 and report back the > results? > > Sam > > On Tue, Oct 22, 2019 at 8:11 AM Alexander W via USRP-users < > [email protected]> wrote: > >> Hey, >> >> I am currently setting up an E320 and want to use both TX Chains >> simultaneously. I first did the benchmark_rate test: >> >> $ ~/pybombs_gnuradio/lib/uhd/examples/benchmark_rate --args >> "addr=192.168.10.2" --duration 60 --channels "0,1" --rx_rate 1e6 >> --rx_subdev "A:0 A:1" >> >> This ran fine and I moved over to gnuradio. The test flowchart consists >> of two sine signal sources as input for one sink block. Arguments in the >> USRP sink block are set to the following: >> >> - Device Address: addr=192.168.10.2 >> - Mb0: SubDev Spec: A:0 A:1 >> - Num Channels: 2 >> >> Rest of the arguments are the default values. Starting the flowchart >> returns: >> ... >> [INFO] [0/Radio_0] Performing CODEC loopback test... >> [INFO] [0/Radio_0] CODEC loopback test passed >> [INFO] [0/Radio_0] Performing CODEC loopback test... >> [INFO] [0/Radio_0] CODEC loopback test passed >> >> >>> Done (return code -11) >> >> I tried to see where this comes from. The segfault is triggered after a >> call to set the center frequency of the second channel: >> ... >> self.uhd_usrp_sink_0 = uhd.usrp_sink( >> ",".join(('addr=192.168.10.2', "")), >> uhd.stream_args( >> cpu_format="fc32", >> args='', >> channels=[], >> ), >> '', >> ) >> self.uhd_usrp_sink_0.set_subdev_spec('A:0 A:1', 0) >> self.uhd_usrp_sink_0.set_center_freq(freq, 0) >> self.uhd_usrp_sink_0.set_normalized_gain(0.5, 0) >> print("91") >> self.uhd_usrp_sink_0.set_antenna('TX/RX', 0) >> print("93") >> self.uhd_usrp_sink_0.set_center_freq(freq, 1) >> <-- Segfault appears in this call >> print("95") >> self.uhd_usrp_sink_0.set_normalized_gain(0.5, 1) >> print("97") >> self.uhd_usrp_sink_0.set_antenna('TX/RX', 1) >> self.uhd_usrp_sink_0.set_samp_rate(samp_rate) >> ... >> >> Used UHD Version: UHD 3.14.1.1-0-g0347a6d8 >> Used GR Version: 3.8.0.0 >> >> Did anyone run into the same issue? As the error code is during the >> config call I am not sure if this connected to a wrong config or something >> else. >> >> Thanks in advance. Regards, >> Alex >> _______________________________________________ >> USRP-users mailing list >> [email protected] >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
