Forum: GNU Radio tunnel.py buffer crash

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Yanyan Z. (Guest)
on 2009-03-12 08:45
(Received via mailing list)
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-tp224...
Sent from the GnuRadio mailing list archive at Nabble.com.
Eric B. (Guest)
on 2009-03-12 18:35
(Received via mailing list)
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
Yanyan Z. (Guest)
on 2009-03-12 19:02
(Received via mailing list)
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
> removed_email_address@domain.invalid
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp224...
Sent from the GnuRadio mailing list archive at Nabble.com.
Eric B. (Guest)
on 2009-03-12 19:19
(Received via mailing list)
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
Yanyan Z. (Guest)
on 2009-03-14 02:57
(Received via mailing list)
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
> removed_email_address@domain.invalid
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp224...
Sent from the GnuRadio mailing list archive at Nabble.com.
Yanyan Z. (Guest)
on 2009-03-19 07:47
(Received via mailing list)
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
> removed_email_address@domain.invalid
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp224...
Sent from the GnuRadio mailing list archive at Nabble.com.
Eric B. (Guest)
on 2009-03-19 19:22
(Received via mailing list)
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
Yanyan Z. (Guest)
on 2009-03-20 05:22
(Received via mailing list)
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-tp224...
Sent from the GnuRadio mailing list archive at Nabble.com.
Eric B. (Guest)
on 2009-03-20 05:36
(Received via mailing list)
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
Yanyan Z. (Guest)
on 2009-03-20 05:49
(Received via mailing list)
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-tp224...
Sent from the GnuRadio mailing list archive at Nabble.com.
Eric B. (Guest)
on 2009-03-20 06:15
(Received via mailing list)
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
Eric B. (Guest)
on 2009-03-20 21:36
(Received via mailing list)
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
Yanyan Z. (Guest)
on 2009-03-26 05:15
(Received via mailing list)
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
> removed_email_address@domain.invalid
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context:
http://www.nabble.com/tunnel.py-buffer-crash-tp224...
Sent from the GnuRadio mailing list archive at Nabble.com.
Eric B. (Guest)
on 2009-03-26 18:48
(Received via mailing list)
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
This topic is locked and can not be replied to.