[Top][All Lists]

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

Re: [Discuss-gnuradio] Recurring memory leak problems with iterative dec

From: Ben Hilburn
Subject: Re: [Discuss-gnuradio] Recurring memory leak problems with iterative decoding [ GNU Radio]
Date: Fri, 10 May 2019 10:00:13 -0400

Ah, interesting. Thanks so much for the update, Michael, and keep us posted! If this reveals a bug in the runtime we'll want to get that filed for 3.8, assuming it hasn't already been fixed.

And, of course, thanks for providing support, Michael!


On Fri, May 10, 2019 at 7:43 AM Michael Dickens <address@hidden> wrote:
FYI: After some work off-list, we think the issue is that Moses is using an older release of GNU Radio ( He's trying to get the version updated to the most recent 3.7 release. When I execute his OOT scripts using a GR devel version a little prior to the current release, I have no memory leak issues. If updating GR doesn't do the trick, then I'll keep working with him to try to narrow down where the issue is occurring (e.g., as Ben notes: concentrating on the `decoded_u8` & memory allocation / freeing). Memory bugs can manifest themselves in "red herring" ways, and I think that's the case here: that GR has a memory bug that's being triggered by his OOT's code & based on casual debugging of the issue it looks like the issue is in his code but in reality it's in GR somehow. More as this progresses ... - MLD

On Thu, May 9, 2019, at 4:03 PM, Ben Hilburn wrote:
Hey Moses -

I don't have an immediate answer for you, but it seems likely the issue is with `decoded_u8`. Before spending time trying to debug why this might be happening when the code is used in GNU Radio versus not, it would be good to figure out where exactly the leak is occurring.

You should be able to test the `decoded_u8` hypothesis by commenting out the existing malloc & free, and just using some hard-coded dummy vector or something similar. Your application obviously won't work, but what you care about is how that affects the memory leak.

Separately, is there a reason you are dynamically allocating that vector? You are freeing the memory within the same scope, anyway. I guess I'm not sure how much data that realistically is, so perhaps that's why you're putting it on the heap?


Discuss-gnuradio mailing list

reply via email to

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