Re: [Discuss-gnuradio] UHD buffer error

[Anton Blad]

On 2012-12-19 19:30, Josh Blum wrote:
> On 12/19/2012 06:04 AM, Anton Blad wrote:
> > 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<float> buffer[SIZE];
> > int nread = 0;
> >
> > while(nread < SIZE)
> > {
> >      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

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

> > 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.