discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] std::bad_alloc in Reed-Solomon decoder


From: Daniel Estévez
Subject: Re: [Discuss-gnuradio] std::bad_alloc in Reed-Solomon decoder
Date: Sun, 6 Jan 2019 11:22:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

El 06/01/19 a las 10:39, Daniel Estévez escribió:
> Hi,
> 
> I am trying to debug a problem that some users have found in the ESEO
> decoder in gr-satellites (https://github.com/daniestevez/gr-satellites).
> 
> The problem is that after running for a lot of time, the Reed-Solomon
> decoder block throws a std::bad_alloc exception, which gets printed out as
> 
> thread[thread-per-block[13]: <block decode_rs_general (10)>]: std::bad_alloc
> 
> It seems I am able to replicate this on my system.
> 
> My question is how to start debugging this. Is there any way in which I
> can try to find what in the decode_rs_general block is throwing the
> std::bad_alloc exception?
> 
> This decode_rs_general block uses Phil Karn's libfec and it doesn't do
> any memory allocation, except on initialization, so I find it weird that
> it's giving a std::bad_alloc. See the source of the block here:
> 
> https://github.com/daniestevez/gr-satellites/blob/master/lib/decode_rs_general_impl.cc

Hi all,

I've just found the problem. The size of the PDU received in the RS
decoder wasn't checked for minimum size. If the PDU was shorter than the
number of parity check bytes, then pmt::init_u8vector was called with a
negative length in

https://github.com/daniestevez/gr-satellites/blob/master/lib/decode_rs_general_impl.cc#L113

Best regards,

Daniel.




reply via email to

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