discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] crashes, memory errors and valgrind


From: Patrick Strasser
Subject: Re: [Discuss-gnuradio] crashes, memory errors and valgrind
Date: Wed, 06 Jun 2012 08:11:51 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050602 Thunderbird/1.0.2 Mnenhy/0.7.2.0

Tom Rondeau wrote on 2012-06-06 01:12:
> On Tue, Jun 5, 2012 at 10:06 AM, Patrick Strasser
> <address@hidden> wrote:
>> Tom Rondeau wrote on 2012-06-04 14:18:
>>> On Sun, Jun 3, 2012 at 2:22 PM, Patrick Strasser
>>> <address@hidden> wrote:
>>>> Full valgrind log in
>>>> http://pastebin.com/7GCs3bWy

>> What seems strange to me is the allocation of a buffer of a non by 8
>> dividable size, that is accessed in blocks of 8 bytes. So the last read
>> always either does not touch the end of the buffer, or it reads beyond
>> the end.
> 
> Sorry, Patrick, I think there was a typo or something in your first
> sentence, and I'm not sure I understood. But from the gist of it, yes,
> if the items used in a block have size 8, then the buffer allocation
> should be sized enough to handle an integer number of items. This is
> true because the scheduler sends the block noutput_items, which are
> the number of items to process (so the buffer size would be
> 8*noutput_items).

To make it more clear:
>From the valgrind log:

==19688== Invalid read of size 8
[...]
==19688==  Address 0x1a200600 is 1 bytes after a block of size 447 alloc'd
[...]
==19688==    by 0x4F7AF67: gr_fir_fff_simd::set_taps(std::vector<float,
std::allocator<float> > const&) (gr_fir_fff_simd.cc:88)
[...]
==19688==    by 0x4F8DF06: gr_make_rational_resampler_base_fff(unsigned
int, unsigned int, std::vector<float, std::allocator<float> > const&)
(gr_rational_resampler_base_fff.cc:45)

I do not completely understand where this number is calculated, but a
buffer of size 447 is allocated, and later accessed in steps of 8. Btw
even if the buffer was a multiple of 8, the read would be out of bounds.
Anyway, reading out of bounds may trigger a segfault if you are lucky,
if you are not, it goes unnoticed and you get wrong/weird results. I
wonder if this stems from an error in the application. Is it possible to
mis-use the API to trigger something like this that would not happen if
everything was used rigth?

I'm sorry if my mails are not always completely clear and
understandable, still trying to improve my English on technical topics
that are new to me ;-)

Regards

Patrick

-- 
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser <patrick dot strasser at  tugraz dot at>
Student of Telematics, Graz Univ. of Technology, Austria




reply via email to

[Prev in Thread] Current Thread [Next in Thread]