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
