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! Cheers, Ben On Fri, May 10, 2019 at 7:43 AM Michael Dickens <michael.dick...@ettus.com> wrote: > FYI: After some work off-list, we think the issue is that Moses is using > an older release of GNU Radio (3.7.11.1). 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 3.7.11.1 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? > > Cheers, > Ben > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
