Re: [Discuss-gnuradio] usrp_spectrum_sense.py segmentation fault problem
On Tue, Dec 20, 2011 at 11:02 AM, Thomas Tsou wrote: > On Tue, Dec 20, 2011 at 5:11 AM, Sebastian Döring > wrote: > >> > -- > >> #0 0x0013a455 in sem_post@@GLIBC_2.1 () from > >> /lib/tls/i686/cmov/libpthread.so.0 > >> #1 0x0810ab61 in PyThread_release_lock (lock=0x0) at > >> ../Python/thread_pthread.h:374 > >> #2 0x080dbad3 in PyEval_ReleaseLock () at ../Python/ceval.c:262 > >> #3 0x00fa6073 in gr_py_feval_dd::calleval(double) () > > This is likely a similar issue with the Python GIL (global interpreter > lock) that occurred previously on the E100. In that case the final > cause was a missing ctypes library. > > > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-June/001479.html > > To find out, try this thread hack. The patch is old, so you will > probably need to apply manually against the current master. > > diff --git a/uhd_spectrum_sense_sum.py b/uhd_spectrum_sense_sum.py > index 70f530f..31bf458 100644 > --- a/uhd_spectrum_sense_sum.py > +++ b/uhd_spectrum_sense_sum.py > @@ -32,7 +32,11 @@ import sys > import math > import struct > import time > +import threading > > +class ThreadClass(threading.Thread): > +def run(self): > +return > > class tune(gr.feval_dd): >""" > @@ -306,6 +310,9 @@ def main_loop(tb): > > > if __name__ == '__main__': > +t = ThreadClass() > +t.start() > + >tb = my_top_block() >try: >tb.start() # start executing flow graph in > another thread... > > Thomas Please let us know if this patch works. I think this has been an outstanding issue in GNU Radio for a while. It'd be good to get a fix for it in. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD underrun problem
On 12/20/2011 04:39 AM, osama mohamed wrote: > > hi all, > > Q1:can any one tell me the common mistakes that lead to the underrun problem > occurrence while transmission > http://files.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes > Q2:also what are the recommended configurations for the send() > function(buffer size , timeout ,delay between samples) > These parameters depend on your application... > Q3:do i have to send the end of burst packet after each call to the send() > function > No. Only set end of burst for the last call to send() within a burst. Q4. I believe you have a USRP1. And you should that USRP1 really only supports a continuous streaming model -> many features are "emulated". So you wont get that timed shutoff immediately when a burst ends. http://files.ettus.com/uhd_docs/manual/html/usrp1.html#missing-and-emulated-features -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_spectrum_sense.py segmentation fault problem
On Tue, Dec 20, 2011 at 5:11 AM, Sebastian Döring wrote: >> -- >> #0 0x0013a455 in sem_post@@GLIBC_2.1 () from >> /lib/tls/i686/cmov/libpthread.so.0 >> #1 0x0810ab61 in PyThread_release_lock (lock=0x0) at >> ../Python/thread_pthread.h:374 >> #2 0x080dbad3 in PyEval_ReleaseLock () at ../Python/ceval.c:262 >> #3 0x00fa6073 in gr_py_feval_dd::calleval(double) () This is likely a similar issue with the Python GIL (global interpreter lock) that occurred previously on the E100. In that case the final cause was a missing ctypes library. http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-June/001479.html To find out, try this thread hack. The patch is old, so you will probably need to apply manually against the current master. diff --git a/uhd_spectrum_sense_sum.py b/uhd_spectrum_sense_sum.py index 70f530f..31bf458 100644 --- a/uhd_spectrum_sense_sum.py +++ b/uhd_spectrum_sense_sum.py @@ -32,7 +32,11 @@ import sys import math import struct import time +import threading +class ThreadClass(threading.Thread): +def run(self): +return class tune(gr.feval_dd): """ @@ -306,6 +310,9 @@ def main_loop(tb): if __name__ == '__main__': +t = ThreadClass() +t.start() + tb = my_top_block() try: tb.start() # start executing flow graph in another thread... Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_spectrum_sense.py segmentation fault problem
On Tue, 20 Dec 2011 11:39:39 +0100 Matthias Wilhelm wrote: Hello, judging from the log, it seems that a value conversion to float is going wrong, but my (uneducated) guess the root cause is a race between threads (this script starts quite a number of threads ..?). I would try to enter larger values for the delays (tune, dwelling delay) and see whether it changes something. This should reduce the probability that two threads want to do different things at the same time. Thanks for your answer but unfortunately this did not work either. I tried it with up to almost 100 times the actual values but the result remains the same. --Matthias Am 20.12.2011 um 11:11 schrieb Sebastian Döring: Hello list, since I got no answer to my last post, I guess what I wrote wasn´t that helpful. I apologize for whatever I did not understand, but I am not familiar with error logs in the context of the problem I have here. I would really appreciate any help with this. Once again my problem: I am getting the famous segmentation fault when trying to launch the usrp_spectrum_sense.py-script. When asked for an error log, I simply launched it in GDB and copy pasted the output plus backtrace. My OS is Ubuntu 10.04, running on a 32-bit machine. Default python version is 2.6. My hardware is the USRP N210 with XCVR2450. I tried to change my default python version (tried 2.5 and 2.7) but it did not help ( but I am also not sure if I have changed all the necessary paths correctly). Nevertheless I returned to 2.6 and have even reinstalled the GNUraduio package (using the build-script) --> nothing changed. uhd_fft.py and so on is working but I really need to get the above mentioned script running, to modify it later on. Thanks in advance for your answers. -Sebastian On Thu, 15 Dec 2011 12:40:02 +0100 "Sebastian Döring" wrote: On Wed, 14 Dec 2011 08:28:57 -0500 "Marcus D. Leech" wrote: On 14/12/11 08:05 AM, Sebastian Döring wrote: Thanks a lot. Code really looks like what I am looking for. Concerning the machine+Python version combinations that cause seg faults: Is there a known combination that works? Seems like mine doesn't. -Sebastian Could you expand on that a bit, please? Perhaps with an error log, and what you were trying to do when you got a segfault? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org I was simply trying to test the script (usrp_spectrum_sense.py 2.4G 2.41G). I have reproduced the error using gdb and this is what I get: -- Starting program: /usr/bin/python usrp_spectrum_sense.py 2.4G 2.41G [Thread debugging using libthread_db enabled] linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-71810ad Warning: this is known to have issues on some machines+Python version combinations to seg fault due to the callback in bin_statitics. If you figure out why, we'd love to hear about it! -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes [New Thread 0xb6afbb70 (LWP 8791)] [New Thread 0xb62fab70 (LWP 8792)] gain = 49.5 [New Thread 0xb5a99b70 (LWP 8793)] [New Thread 0xb5298b70 (LWP 8794)] [New Thread 0xb4a56b70 (LWP 8795)] [New Thread 0xb40ffb70 (LWP 8796)] [New Thread 0xb38feb70 (LWP 8797)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb38feb70 (LWP 8797)] 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 -- The backtrace says: -- #0 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 #1 0x0810ab61 in PyThread_release_lock (lock=0x0) at ../Python/thread_pthread.h:374 #2 0x080dbad3 in PyEval_ReleaseLock () at ../Python/ceval.c:262 #3 0x00fa6073 in gr_py_feval_dd::calleval(double) () from /usr/local/lib/python2.6/dist-packages/gnuradio/gr/_gnuradio_core_general.so #4 0x0083a6cd in gr_bin_statistics_f::enter_tune_delay() () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #5 0x0083a788 in gr_bin_statistics_f::work(int, std::vector >&, std::vector >&) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #6 0x007d70e7 in gr_sync_block::general_work(int, std::vector >&, std::vectorconst*, std::allocator >&, std::vector >&) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #7 0x007ba475 in gr_block_executor::run_one_iteration() () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #8 0x007da549 in gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #9 0x007d3fcd in boost::detail::function::void_function_obj_invoker0, void>::invoke(boost::detail::function::
[Discuss-gnuradio] UHD underrun problem
hi all, Q1:can any one tell me the common mistakes that lead to the underrun problem occurrence while transmission Q2:also what are the recommended configurations for the send() function(buffer size , timeout ,delay between samples) Q3:do i have to send the end of burst packet after each call to the send() function ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Software Radio Implementation Forum workshop
Sounds Good! Looking forward for your presentation! On 12/20/2011 3:20 AM, Tom Rondeau wrote: Hey everyone, I just wanted to let everyone know that I will be speaking at the new Software Radio Implementation Forum's (SRIF) first workshop this January. It's in Hong Kong, but registration is free for people in that part of the world. You can find more details about it here: http://srif2012.inc.cuhk.edu.hk/ I'm looking forward to it (and exploring Hong Kong, as well)! I hope I can meet some more of our users. Tom ___ 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
Re: [Discuss-gnuradio] usrp_spectrum_sense.py segmentation fault problem
Hello, judging from the log, it seems that a value conversion to float is going wrong, but my (uneducated) guess the root cause is a race between threads (this script starts quite a number of threads ..?). I would try to enter larger values for the delays (tune, dwelling delay) and see whether it changes something. This should reduce the probability that two threads want to do different things at the same time. --Matthias Am 20.12.2011 um 11:11 schrieb Sebastian Döring: > Hello list, > > since I got no answer to my last post, I guess what I wrote wasn´t that > helpful. > I apologize for whatever I did not understand, but I am not familiar with > error logs in the context of the problem I have here. > I would really appreciate any help with this. > > Once again my problem: I am getting the famous segmentation fault when trying > to launch the usrp_spectrum_sense.py-script. > When asked for an error log, I simply launched it in GDB and copy pasted the > output plus backtrace. > > My OS is Ubuntu 10.04, running on a 32-bit machine. Default python version is > 2.6. My hardware is the USRP N210 with XCVR2450. > > I tried to change my default python version (tried 2.5 and 2.7) but it did > not help ( but I am also not sure if I have changed all the necessary paths > correctly). > Nevertheless I returned to 2.6 and have even reinstalled the GNUraduio > package (using the build-script) --> nothing changed. > > uhd_fft.py and so on is working but I really need to get the above mentioned > script running, to modify it later on. > > > Thanks in advance for your answers. > > -Sebastian > > > On Thu, 15 Dec 2011 12:40:02 +0100 > "Sebastian Döring" wrote: >> On Wed, 14 Dec 2011 08:28:57 -0500 >> "Marcus D. Leech" wrote: >>> On 14/12/11 08:05 AM, Sebastian Döring wrote: Thanks a lot. Code really looks like what I am looking for. Concerning the machine+Python version combinations that cause seg faults: Is there a known combination that works? Seems like mine doesn't. -Sebastian >>> Could you expand on that a bit, please? Perhaps with an error log, and >>> what you were trying to do when >>> you got a segfault? >>> -- >>> Principal Investigator >>> Shirleys Bay Radio Astronomy Consortium >>> http://www.sbrac.org >> I was simply trying to test the script (usrp_spectrum_sense.py 2.4G 2.41G). >> I have reproduced the error using gdb and this is what I get: >> -- >> Starting program: /usr/bin/python usrp_spectrum_sense.py 2.4G 2.41G >> [Thread debugging using libthread_db enabled] >> linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-71810ad >> Warning: this is known to have issues on some machines+Python version >> combinations to seg fault due to the callback in bin_statitics. If you >> figure out why, we'd love to hear about it! >> -- Opening a USRP2/N-Series device... >> -- Current recv frame size: 1472 bytes >> -- Current send frame size: 1472 bytes >> [New Thread 0xb6afbb70 (LWP 8791)] >> [New Thread 0xb62fab70 (LWP 8792)] >> gain = 49.5 >> [New Thread 0xb5a99b70 (LWP 8793)] >> [New Thread 0xb5298b70 (LWP 8794)] >> [New Thread 0xb4a56b70 (LWP 8795)] >> [New Thread 0xb40ffb70 (LWP 8796)] >> [New Thread 0xb38feb70 (LWP 8797)] >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0xb38feb70 (LWP 8797)] >> 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 >> -- >> The backtrace says: >> -- >> #0 0x0013a455 in sem_post@@GLIBC_2.1 () from >> /lib/tls/i686/cmov/libpthread.so.0 >> #1 0x0810ab61 in PyThread_release_lock (lock=0x0) at >> ../Python/thread_pthread.h:374 >> #2 0x080dbad3 in PyEval_ReleaseLock () at ../Python/ceval.c:262 >> #3 0x00fa6073 in gr_py_feval_dd::calleval(double) () >> from >> /usr/local/lib/python2.6/dist-packages/gnuradio/gr/_gnuradio_core_general.so >> #4 0x0083a6cd in gr_bin_statistics_f::enter_tune_delay() () >> from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 >> #5 0x0083a788 in gr_bin_statistics_f::work(int, std::vector> std::allocator >&, std::vector >&) >> () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 >> #6 0x007d70e7 in gr_sync_block::general_work(int, std::vector> std::allocator >&, std::vector >> >&, std::vector >&) () >> from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 >> #7 0x007ba475 in gr_block_executor::run_one_iteration() () >> from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 >> #8 0x007da549 in >> gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr) () >> from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 >> #9 0x007d3fcd in >> boost::detail::function::void_function_obj_invoker0, >> vo
[Discuss-gnuradio] usrp_spectrum_sense.py segmentation fault problem
Hello list, since I got no answer to my last post, I guess what I wrote wasn´t that helpful. I apologize for whatever I did not understand, but I am not familiar with error logs in the context of the problem I have here. I would really appreciate any help with this. Once again my problem: I am getting the famous segmentation fault when trying to launch the usrp_spectrum_sense.py-script. When asked for an error log, I simply launched it in GDB and copy pasted the output plus backtrace. My OS is Ubuntu 10.04, running on a 32-bit machine. Default python version is 2.6. My hardware is the USRP N210 with XCVR2450. I tried to change my default python version (tried 2.5 and 2.7) but it did not help ( but I am also not sure if I have changed all the necessary paths correctly). Nevertheless I returned to 2.6 and have even reinstalled the GNUraduio package (using the build-script) --> nothing changed. uhd_fft.py and so on is working but I really need to get the above mentioned script running, to modify it later on. Thanks in advance for your answers. -Sebastian On Thu, 15 Dec 2011 12:40:02 +0100 "Sebastian Döring" wrote: On Wed, 14 Dec 2011 08:28:57 -0500 "Marcus D. Leech" wrote: On 14/12/11 08:05 AM, Sebastian Döring wrote: Thanks a lot. Code really looks like what I am looking for. Concerning the machine+Python version combinations that cause seg faults: Is there a known combination that works? Seems like mine doesn't. -Sebastian Could you expand on that a bit, please? Perhaps with an error log, and what you were trying to do when you got a segfault? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org I was simply trying to test the script (usrp_spectrum_sense.py 2.4G 2.41G). I have reproduced the error using gdb and this is what I get: -- Starting program: /usr/bin/python usrp_spectrum_sense.py 2.4G 2.41G [Thread debugging using libthread_db enabled] linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-71810ad Warning: this is known to have issues on some machines+Python version combinations to seg fault due to the callback in bin_statitics. If you figure out why, we'd love to hear about it! -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes [New Thread 0xb6afbb70 (LWP 8791)] [New Thread 0xb62fab70 (LWP 8792)] gain = 49.5 [New Thread 0xb5a99b70 (LWP 8793)] [New Thread 0xb5298b70 (LWP 8794)] [New Thread 0xb4a56b70 (LWP 8795)] [New Thread 0xb40ffb70 (LWP 8796)] [New Thread 0xb38feb70 (LWP 8797)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb38feb70 (LWP 8797)] 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 -- The backtrace says: -- #0 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 #1 0x0810ab61 in PyThread_release_lock (lock=0x0) at ../Python/thread_pthread.h:374 #2 0x080dbad3 in PyEval_ReleaseLock () at ../Python/ceval.c:262 #3 0x00fa6073 in gr_py_feval_dd::calleval(double) () from /usr/local/lib/python2.6/dist-packages/gnuradio/gr/_gnuradio_core_general.so #4 0x0083a6cd in gr_bin_statistics_f::enter_tune_delay() () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #5 0x0083a788 in gr_bin_statistics_f::work(int, std::vector >&, std::vector >&) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #6 0x007d70e7 in gr_sync_block::general_work(int, std::vector >&, std::vectorconst*, std::allocator >&, std::vector >&) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #7 0x007ba475 in gr_block_executor::run_one_iteration() () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #8 0x007da549 in gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #9 0x007d3fcd in boost::detail::function::void_function_obj_invoker0, void>::invoke(boost::detail::function::function_buffer&) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #10 0x009515f5 in boost::detail::thread_data ::run() () from /usr/local/lib/libgruel-3.5.0rc0.so.0.0.0 #11 0x009db7c5 in thread_proxy () from /usr/lib/libboost_thread.so.1.40.0 #12 0x0013396e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #13 0x003f1a4e in clone () from /lib/tls/i686/cmov/libc.so.6 -- -Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
