Hello Ben, In order to test the current hypothesis, I upgraded my system from Ubuntu 16.04 to 18.04 and GNU Radio from 3.7.11 to 3.7.13.5. Still, the leak persists. Surprisingly, Michael didn't experience the issue on his MacOS, running the exact code I'm running at the moment. I'm not sure what could cause the issue in Ubuntu.
Regards, Moses. On Wed, May 15, 2019 at 7:46 AM Ben Hilburn <bhilb...@gnuradio.org> wrote: > Sounds good, Moses! Keep us posted. > > Cheers, > Ben > > On Sat, May 11, 2019 at 9:16 PM Moses Browne Mwakyanjala < > mbkit...@gmail.com> wrote: > >> Hello Ben, >> I did try to comment out the decode_u8 vector, without any luck. >> Interestingly, Michael was able to run the program successfully on his >> platform, which turned out to be much newer than the one I'm using (3.7.11). >> I'm in the process of installing a new release of GNU Radio and test the >> hypothesis. Unfortunately, the installation of the latest GNU Radio >> releases is surprisingly painful and lengthy. >> I will let you know what happens after I have tested the program on the >> new installation. >> >> Regards, >> Moses. >> >> On Thu, May 9, 2019 at 10:02 PM Ben Hilburn <bhilb...@gnuradio.org> >> 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 >>> >>> On Wed, May 8, 2019 at 1:33 PM Moses Browne Mwakyanjala < >>> mbkit...@gmail.com> wrote: >>> >>>> Hello Ben, >>>> Yes. There are no memory leaks when the block is disabled. >>>> >>>> Regards, >>>> Moses. >>>> >>>> On Wed, May 8, 2019 at 5:50 PM Ben Hilburn <bhilb...@gnuradio.org> >>>> wrote: >>>> >>>>> Hi Moses - >>>>> >>>>> And just to confirm, if you remove your LDPC block from that flowgraph >>>>> or replace it with a passthrough, you don't see the leak? >>>>> >>>>> Cheers, >>>>> Ben >>>>> >>>>> On Tue, May 7, 2019 at 7:24 PM Moses Browne Mwakyanjala < >>>>> mbkit...@gmail.com> wrote: >>>>> >>>>>> Hello Ben, >>>>>> Thanks. >>>>>> For LDPC, the executable can be found at >>>>>> >>>>>> *gr-ccsds/examples/LDPC/ldpc_2/build-ldpc_decoder-Desktop-Debug/ldpc_decoder.* >>>>>> The C++ executable for Turbo code can be found at >>>>>> *gr-ccsds/lib/fec/turbo/deepspace-turbo/bin/deepspace_turbo* >>>>>> >>>>>> I'm not very familiar with Valgrind so I monitored the memory usage >>>>>> by looking at system monitor on my Ubuntu laptop. The memory usage is >>>>>> almost constant, at around 17.1 Mbs for the ldpc_decoder executable. On >>>>>> GNU >>>>>> Radio, the memory usage jumps by huge steps (100Mb) in a matter of >>>>>> seconds >>>>>> until all the memory (the ram is around 8 gigs) is fully consumed. >>>>>> >>>>>> Thanks for links to the memory buffer blog post. I will have a look. >>>>>> Regards, >>>>>> Moses. >>>>>> >>>>>> On Tue, May 7, 2019 at 10:13 PM Ben Hilburn <bhilb...@gnuradio.org> >>>>>> wrote: >>>>>> >>>>>>> Hey Moses - >>>>>>> >>>>>>> This is really cool work! Thanks so much for sharing it. Michael's >>>>>>> suggestion of pushing it was a good one. I haven't looked at the code >>>>>>> yet, >>>>>>> but: >>>>>>> >>>>>>> The code was able to run smoothly in a C++ application but >>>>>>>> experienced memory leaks in GNU Radio. >>>>>>>> >>>>>>> >>>>>>> I'm curious how confident you are in this? It might be worthwhile to >>>>>>> run the pure-C++ version through Valgrind just to double-check, if you >>>>>>> haven't already. >>>>>>> >>>>>>> I also have one question regarding buffering in GNU Radio. Since >>>>>>>> iterative decoding with a large number of iterations and large block >>>>>>>> sizes >>>>>>>> takes time to complete, the input pmt data that is not consumed >>>>>>>> immediately >>>>>>>> will have to be stored somewhere. Is that the case? Could that be the >>>>>>>> reason for the memory leak? >>>>>>>> >>>>>>> >>>>>>> Things do get stored until buffers and full, and then backpressure >>>>>>> builds up through the flowgraph. This shouldn't cause memory leaks. >>>>>>> >>>>>>> For a more thorough explanation of this, check out this excellent >>>>>>> blog post from Marcus Mueller! >>>>>>> >>>>>>> https://www.gnuradio.org/blog/2017-01-05-buffers/ >>>>>>> >>>>>>> Cheers, >>>>>>> Ben >>>>>>> >>>>>>
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
