# UHD buffer error

**URL:** <https://www.ruby-forum.com/t/uhd-buffer-error/225183>\
**Category:** GNU Radio\
**Created:** [December 19, 2012, 1:05pm UTC](https://www.ruby-forum.com/t/uhd-buffer-error/225183 "2012-12-19T13:05:22Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\
**Post date:** [December 19, 2012, 1:05pm UTC](https://www.ruby-forum.com/t/uhd-buffer-error/225183/1 "2012-12-19T13:05:22Z")

</div>

Hi list,

I am using a USRP1 with UHD directly in C++, and several times I got the  
following error within a few seconds after starting my application:

UHD Error:  
The receive packet handler caught an exception.  
recv buffer smaller than vrt packet offset

I haven’t seen this error before, and after rebooting the USRP it went  
away. Still, I would like to know what the problem was.

Essentially, my USRP code looks like this:

complex buffer[SIZE];  
int nread = 0;

while(nread \< SIZE)  
{  
nread += streamer-\>recv(rx\_streamer::buffs\_type(buffer+nread,  
SIZE-nread, rx\_meta);  
}

I tried with SIZE=4096 and SIZE=65536 before rebooting the USRP. Could  
there be a problem with this implementation, for example if recv returns  
a value close to SIZE so that the next call is made with a small buffer  
size? The UHD version is UHD\_003.004.003-276-unstable.

Thanks in advance for any help,  
Anton Blad

---

<div class="post-metadata">

**Author:** ![Anton\_Blad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/6bbea6/32.png) [@Anton\_Blad](https://www.ruby-forum.com/u/Anton_Blad)\
**Post date:** [December 19, 2012, 7:31pm UTC](https://www.ruby-forum.com/t/uhd-buffer-error/225183/2 "2012-12-19T19:31:28Z")

</div>

On 12/19/2012 06:04 AM, Anton Blad wrote:

> away. Still, I would like to know what the problem was.  
> }

Whats happening here? Is it getting stuck in the while loop?

Here is an example use case of recv in gr-uhd source block:  
[http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/lib/gr\_uhd\_usrp\_source.cc#n331](http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/lib/gr_uhd_usrp_source.cc#n331)

> I tried with SIZE=4096 and SIZE=65536 before rebooting the USRP. Could  
> there be a problem with this implementation, for example if recv returns  
> a value close to SIZE so that the next call is made with a small buffer

Basically, the rx streamer will always try to write everything it can  
from internal buffers into your buffer. If there is not room, partial  
buffers are saved for the next call.

-josh

---

<div class="post-metadata">

**Author:** ![Anton\_Blad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/6bbea6/32.png) [@Anton\_Blad](https://www.ruby-forum.com/u/Anton_Blad)\
**Post date:** [December 20, 2012, 10:29am UTC](https://www.ruby-forum.com/t/uhd-buffer-error/225183/3 "2012-12-20T10:29:25Z")

</div>

On 2012-12-19 19:30, Josh B. wrote:

> > ```
> > nread += streamer->recv(rx_streamer::buffs_type(buffer+nread),
> > 
> > ```
> > 
> > SIZE-nread, rx\_meta);  
> > }

Hi Josh, and thanks for your answer,

> Whats happening here? Is it getting stuck in the while loop?

It’s not getting stuck. The reason I wrote it like this is that I’ve  
seen recv return fewer bytes than requested, and I want to process  
buffers of a fixed size. The program received data for a few seconds,  
and then segfaulted after printing the message, and this happened  
consistently several times until I rebooted the USRP. Unfortunately,  
this was during a presentation, so I did not have time to run with gdb.

Looking at the UHD code, as far as I can tell, the recv buffer mentioned  
in the error message is the receive buffer from the transport layer, and  
not the one from the application.

> Here is an example use case of recv in gr-uhd source block:  
> [http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/lib/gr\_uhd\_usrp\_source.cc#n331](http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/lib/gr_uhd_usrp_source.cc#n331)

I don’t see any big differences. The only thing I can think about is  
that the scheduler potentially could guarantee a minimum value of  
noutput\_items so that recv always is called with a large enough buffer.  
On the other hand, if the problem is with the transport layer buffer I  
don’t see why the size of the application buffer would matter. Anyway,  
I’d like to know if there is a potential problem with my code. If not, I  
guess the only thing to do is to see if it happens again and be ready  
with gdb..

Regards,  
Anton