Tunnel.py buffer crash

Hi,

Has anybody got this error when running tunnel.py in gnuradio-example
(with
virtual IP addresses set up on two PCs and ping each other on this
tunnel)?

./gr_buffer.h:125: unsigned int gr_buffer::index_add(unsigned int,
unsigned
int): Assertion `s < d_bufsize’ failed.

I got this problem on both the sender and receiver side. Thanks a lot.

Yanyan

View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp22470731p22470731.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Wed, Mar 11, 2009 at 11:44:59PM -0700, yyzhuang wrote:

Yanyan

Can you please provide the exact command line that you used to invoke
tunnel.py? Which version of GNU Radio were you using? trunk (which
rev) or tarball (which rev)?

Thanks,
Eric

Hi Eric,

The command line: sudo ./tunnel.py --freq 2.44G --bitrate 500k -v (is
bitrate has something to do with buffer?)

I installed GNU Radio from here: svn co
http://gnuradio.org/svn/gnuradio/branches/releases/3.1 gnuradio

I never had that buffer problem before I moved the 2 boxes to another
lab
(from computer science lab to ee lab). Will it because of the higher
interference in the busier channel that caused too many packets being
queued
in the buffer, and caused the buffer over flow?

Thanks a ton.

Yanyan

Eric B. wrote:

./gr_buffer.h:125: unsigned int gr_buffer::index_add(unsigned int,

Thanks,
Eric


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page


View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp22470731p22480884.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Thu, Mar 12, 2009 at 10:01:28AM -0700, yyzhuang wrote:

Hi Eric,

The command line: sudo ./tunnel.py --freq 2.44G --bitrate 500k -v (is
bitrate has something to do with buffer?)

I installed GNU Radio from here: svn co
http://gnuradio.org/svn/gnuradio/branches/releases/3.1 gnuradio

Thanks.

I never had that buffer problem before I moved the 2 boxes to another lab
(from computer science lab to ee lab). Will it because of the higher
interference in the busier channel that caused too many packets being queued
in the buffer, and caused the buffer over flow?

No, the error message most likely indicates an internal error in one
of the blocks. If you can reproduce the problem and can grab a gdb
backtrace when it happens, that would be very helpful in figuring out
which block has the problem.

Here’s how to use gdb with python. Add the code below to the top of
tunnel.py, after all the imports.

Debugging with gdb

If your block isn't working, and you can't sort it out through 

python
test cases or a few printfs in the code, you may want to use gdb to
debug it. The trick of course is that all of GNU Radio, including
your
new block, is dynamically loaded into python for execution.

Try this: In your python test code, after the relevant imports, 

print
out the process id and wait for a keystroke. In another window run
gdb
and tell it to attach to the python process with the given process
id. At this point you can set breakpoints or whatever in your code.
Go
back to the python window and hit Enter so it’ll continue.

  #!/usr/bin/env python
  from gnuradio import gr


  # insert this in your test code...
  import os
  print 'Blocked waiting for GDB attach (pid = %d)' % (os.getpid(),)
  raw_input ('Press Enter to continue: ')
  # remainder of your test code follows...

Eric

Hi Eric,

We read through the code. gr_buffer is a circular/ring buffer, so when
reading/writing through it, we need to take modular into account. The
assert
error, it’s line 125 in gr_buffer.h
(gnuradio/gnuradio-core/src/lib/runtime/gr_buffer.h):

unsigned
index_add (unsigned a, unsigned b)
{
unsigned s = a + b;

if (s >= d_bufsize)
  s -= d_bufsize;

assert (s < d_bufsize);
return s;

}

It is invoked by

void
gr_buffer::update_write_pointer (int nitems)
{
scoped_lock guard(*mutex());
d_write_index = index_add (d_write_index, nitems);
}

void
gr_buffer_reader::update_read_pointer (int nitems)
{
scoped_lock guard(*mutex());
d_read_index = d_buffer->index_add (d_read_index, nitems);
}

I think it wants to add d_write_index or d_read_index by nitems. But
when
arrival rate is higher than service rate, buffer overflow occurs. Do you
know how to increase the buffer size? Thanks.

Yanyan

Eric B. wrote:

backtrace when it happens, that would be very helpful in figuring out
new block, is dynamically loaded into python for execution.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page


View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp22470731p22594030.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Wed, Mar 18, 2009 at 10:36:17PM -0700, yyzhuang wrote:

{

scoped_lock guard(*mutex());
d_read_index = d_buffer->index_add (d_read_index, nitems);
}

I think it wants to add d_write_index or d_read_index by nitems. But when
arrival rate is higher than service rate, buffer overflow occurs. Do you
know how to increase the buffer size? Thanks.

The problem is most likely not in this code, but in a gr_block that is
misbehaving. Increasing the buffer size will not fundamentally alter
the behavior.

Eric

Is it possible a GNU Radio distribution problem? In the new lab we
installed
the whole GNU Radio again. Thanks.

Yanyan

Eric B. wrote:

}
void
The problem is most likely not in this code, but in a gr_block that is


View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp22470731p22613693.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Thu, Mar 19, 2009 at 08:21:43PM -0700, yyzhuang wrote:

Is it possible a GNU Radio distribution problem? In the new lab we installed
the whole GNU Radio again. Thanks.

Yanyan

Can you more-or-less-reliably reproduce the problem?
If so, how often does it occur? Every time? Once every 10 times?

If you’ve got a way to reproduce the problem, we can solve it.

Eric

Hi Eric,

Sorry I was busy yesterday and today so I got to debug just now.

I did what you told me to then use “(gdb) attach $pid”. then “(gdb)
continue”. the process seems slowed down quite a lot and almost halt
(but it
shouldn’t be). in this case I can’t make the process crash and backtrace
in
gdb. maybe I did something wrong that made the process doesn’t crash…
I’m
a newbie of gnu radio and gdb…

Yanyan

Eric B. wrote:

backtrace when it happens, that would be very helpful in figuring out
new block, is dynamically loaded into python for execution.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page


View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp22470731p22507897.html
Sent from the GnuRadio mailing list archive at Nabble.com.

I’m sorry.

If we do ./tunnel and ping between two boxes over the air, both tx and
rx
breaks right after a few ping. They don’t break at the same time though,
but
it does happen every time. If we do over channel emulator (by connecting
the
antenna of USRP to the emulator), we can ping the two machines much
longer,
but it still breaks.

Sorry again, no offense. I didn’t mean to be rude or something.

Yanyan

Eric B. wrote:

If so, how often does it occur? Every time? Once every 10 times?


View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp22470731p22613836.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Thu, Mar 19, 2009 at 08:50:13PM -0700, yyzhuang wrote:

I’m sorry.

If we do ./tunnel and ping between two boxes over the air, both tx and rx
breaks after a few ICMP packets exchange. They don’t break at the same time
though, but it does happen every time. If we do over channel emulator (by
connecting the antenna of USRP to the emulator), we can ping the two
machines much longer, but it still breaks.

Sorry again, no offense. I didn’t mean to be rude or something.

No problem. I didn’t take it that way.

I’m busy with something else right now, but I think I can get you some
instrumented code that will locate the offending block sometime
tomorrow. It’s great news that it fails regularly for you!

Eric

Hi Eric,

We’ve made a stupid mistake. My friend installed gnuradio from trunk in
their lab. I just figure out this problem. After we reinstalled there’s
no
buffer problem anymore.

Thanks!
Yanyan

Eric B. wrote:

though, but it does happen every time. If we do over channel emulator
tomorrow. It’s great news that it fails regularly for you!
Thanks!
Eric


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page


View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp22470731p22715346.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Wed, Mar 25, 2009 at 08:14:32PM -0700, yyzhuang wrote:

Hi Eric,

We’ve made a stupid mistake. My friend installed gnuradio from trunk in
their lab. I just figure out this problem. After we reinstalled there’s no
buffer problem anymore.

Thanks!
Yanyan

Thanks for letting us know it’s working.

Eric

On Thu, Mar 19, 2009 at 09:12:00PM -0700, Eric B. wrote:

Sorry again, no offense. I didn’t mean to be rude or something.

No problem. I didn’t take it that way.

I’m busy with something else right now, but I think I can get you some
instrumented code that will locate the offending block sometime
tomorrow. It’s great news that it fails regularly for you!

Eric

We fixed a bug yesterday in gr_clock_recovery_mm_ff.cc [10646], which
is used by the GMSK demodulator, and which could be causing the
problem you are seeing.

Can you please checkout a copy of the trunk, build and install it and
try to reproduce the problem you’ve been seeing?

Thanks!
Eric