Re: [Discuss-gnuradio] usrp_spectrum_sense.py segmentation fault problem

[Matthias Wilhelm]

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" <address@hidden> wrote:
>> On Wed, 14 Dec 2011 08:28:57 -0500
>> "Marcus D. Leech" <address@hidden> 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<void const*, 
>> std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&) 
>> () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0
>> #6  0x007d70e7 in gr_sync_block::general_work(int, std::vector<int, 
>> std::allocator<int> >&, std::vector<void const*, std::allocator<void const*> 
>> >&, std::vector<void*, std::allocator<void*> >&) ()
>>   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<gr_block>) ()
>>   from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0
>> #9  0x007d3fcd in 
>> boost::detail::function::void_function_obj_invoker0<gruel::thread_body_wrapper<tpb_container>,
>>  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<boost::function0<void> 
>>> ::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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio