Thank you to all of you who answered to this silly questions.

It's confusing because I did fresh install several times

Anyway, I'll try with those advices

Thank you very much

2011/11/27 Marcus D. Leech <[email protected]>

> **
>
> I have a number of problems in testing benchmark program under a
> gr-digital directory from GR 3.5.0rc0
>
>  1. Problem about free() side or segmentation fault on tx
> Whatever I select modulation schemes(-m) or bit rate(-r), carrier
> frequency(-f) and other options
> either a free()-related problem or a segmentation fault must occur.
>
> a. free()-related problem
>
>   $ ./benchmark_tx.py -f 450e6 --tx-amplitude=0.02 -r 1M
>
>  linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-06d0032
>
>  >>> gr_fir_ccf: using SSE
>
>  -- Opening a USRP1 device...
>
>  -- Using FPGA clock rate of 64.000000MHz...
>
>
> ................................................................................................................................U..................................
>
> ....................................................................................................................................................................
> ...............................................................
> ............................................................
> .........................................
> .................................................
> ............................................................
> .......................................................
> .............**** glibc detected *** python: free(): invalid pointer:
> 0x0a42a2a8 ****
>
>  ======= Backtrace: =========
>
>  /lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0x17ebc2]
>
>  /lib/i386-linux-gnu/libc.so.6(+0x6f862)[0x17f862]
>
>  /lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0x18294d]
>
>  /usr/lib/libboost_thread.so.1.46.1(delete_epoch_tss_data+0x1b)[0x2f947b]
>
>  /lib/i386-linux-gnu/libpthread.so.0(+0x6b1e)[0xe55b1e]
>
>  /lib/i386-linux-gnu/libpthread.so.0(+0x6d3f)[0xe55d3f]
>
>  /lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0x1e20ce]
>
>  ======= Memory map: ========
>
>  00110000-00286000 r-xp 00000000 08:01 918438     /lib/i386-linux-gnu/
> libc-2.13.so
>
>  (and bunch of things representing a memory map follow, I just skipped it)
>
>
>   Sometimes it says* *** glibc detected *** python: double free(): ~ ****,
> instead
>
>  b. Segmentation fault
>
>  $ ./benchmark_tx.py -f 450e6 --tx-amplitude=0.05 -r 500k --tx-gain=30 -m
> dqpsk
> linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-06d0032
> >>> gr_fir_ccf: using SSE
> -- Opening a USRP1 device...
> -- Using FPGA clock rate of 64.000000MHz...
>
> ........................................................................................U.............................................................................
>
> ......................................................................................................................................................................
> .
> .........................................................
> ............................................................
> ..................................................
> ......................................................................
> ............................................................
> .....................................
> .*Segmentation fault*
>
>
>   I feel that if a bit rate is higher, then it occurs more earlier. (I
> mean the faster bit rate, the fewer 'dots' and then, Segmentation fault.)
>
>
>
>  Specification of the PC on the receiver side is like this:
>
>      Host
>
>       CPU: Intel Core2 Duo P9300 @ 1.60 GHz
>
>       RAM: 4.00 GB
>
>       OS: Win7 32bit
>
>       Guest
>
>       Platform: VMWare Workstation 7.x
>
>        Memory allocated: 1.00 GB
> OS: Ubuntu 11.10 32bit
>
>     Did you perhaps update to the latest UHD without upgrading Gnu Radio?
>  There was a significant ABI change that can cause unpredictable
>   behaviour like this.
>
> I wonder if it's time for gr-uhd to check the API/ABI version number of
> the UHD library below it, and produce at least an proper error, rather
>   than wandering off into the weeds.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Seokseong Jeon, PhD Candidate
Communication & Networks Lab
IT Convergence Engineering (ITCE), POSTECH, Korea
+82 10 8338 1229, gee.songsong at gmail . com
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to