> 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.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment