On Sat, Jan 7, 2012 at 1:45 PM, Ryan Pape <[email protected]> wrote:
> > I have a standalone application, that follows the following pattern: > > While True: > > x = dequeue() > > if X=A > > tb = gr.top_block() > > <create blocks> > > tb.connect(<blocks>) > > tb.run() > if X=B > > similar but different set of blocks > > > Is this a right or wrong way to instantiate and use multiple flow graphs? > I am creating an entirely new top_block() on each iteration, of which > there are 10-20 minute. Over the course of several days, memory > consumption grows and performance slows. > > As I try and narrow down the cause, I want to first rule out whether I am > doing anything wrong on the GNURadio side of the equation by how I am > creating and using multiple graphs. > > Thanks > Hi Ryan, I might have misunderstood what you are doing. So just to be sure, you create a top block, let it run to completion, then create and run another top block until it completes. This continues indefinitely. Right? I just want to make sure that you want to run these one at a time, in which case, what you have here looks fine. Now to the memory issues. Every time you create a new top block like you do, it should delete the old one and free up all memory. Obviously, this doesn't seem to be happening. Firs thing to try is to use a "del tb" after the "tb.run()" line to yell at Python to delete the object. The probably isn't the problem, but it's easy enough to try. If that doesn't help, see if you can run the program under valgrind and get a report of the memory leaks: valgrind --tool=memcheck python <program> And see if you can identify where there's unfreed memory after running a top block. We have no runtime memory leak problems (since we've run these things for days and weeks if not longer), but we might not be cleaning everything up in the end. There are other potential problems with some libraries we're linking against. If it's a problem with GNU Radio, we'll obviously work to correct it. Thanks, Tom
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
