[Discuss-gnuradio] Problems in benchmark_xx.py (free(), Segmentation fault, overrun, CRC check, FLL)

[Songsong Gee]

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

2. No CPM demod in benchmark_rx.py

It's not a big problem, just curiosity. There is a CPM mod options on tx.py, but it's invalid option for rx.py

3. No output from rx_callback in benchmark_rx.py

I strongly believe that I have to modify carrier sensing threshold in receive_path.py for the receiver in order to sense a carrier.

# Carrier Sensing Blocks

alpha = 0.001

thresh = 30   # in dB, will have to adjust

self.probe = gr.probe_avg_mag_sqrd_c(thresh,alpha)

Thus, I changed it with the - 60 dB (in my test environment, --tx-gain=30, --rx-gain=50, then a received signal strength is above -60 dB, observed with uhd_fft.py), and nothing changed elsewhere.

After changing it, however, when I run benchmark_rx.py, it prints nothing for received packets

$ ./benchmakr_rx.py -f 450e6 -r 500k --rx-gain=50 -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...

That's all. or, Problem 4. (below) occurs.

4. Overrun on the receiver side

$ ./benchmakr_rx.py -f 450e6 -r 500k --rx-gain=50 -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...

OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

Lots of 'O's, which indicate Overrun,are printed.

Specification of the PC on the receiver side is like this:

Host

CPU: Intel Core2 Duo P9700 @ 2.80 GHz

RAM: 6.00 GB

OS: Win7 32bit

Guest

Platform: VMWare Workstation 7.x

Memory allocated: 1.00 GB

OS: Ubuntu 11.10 32bit

5. All of received packets fail on CRC check

Once a packet is received (if it really happens,) it always fails to pass the CRC check.

I did not specify an access code, thus program will use a default access code on both tx/rx sides.

I also tried changing modulation, carrier sensing threshold, but the result is same.

And probably because of CRC check failure, it also fails on unpacking payload. (pktno,) = struct.unpack('!H', payload[0:2]), but I'm not sure.

So, I got rid of a part printing pktno, then I got this:

ok = False n_rcvd = (n_rcvd) n_right = 0

6. FLL bugs

I heard that there is a bug on FLL which is essential for *psk mod/demod

Are some of problems I mentioned related with this issue?

Each of them belongs to different issue, but not wanting to spam mails, I just put together into this.

--

Seokseong Jeon, PhD Candidate

Communication & Networks Lab

IT Convergence Engineering (ITCE), POSTECH, Korea

+82 10 8338 1229, gee.songsong at gmail . com