Hi Joe, this sounds like you want to use ctrlport performance monitor. This might show you situations where certain buffers fill up while others are empty. Of course, I assume you use a flowgraph with parallel data flows. In such situations a very slight rate mismatch or bugs that cause lost samples may ultimately lead to asynchronicity. Your question: "Block such-and-such was provided X inputs and space for Y outputs, it consumed A and produced B", should be answerable with this tool. At least on a statistical level. Besides, 100 threads seems like a situation where you want to start to combine tasks into one thread. But that's a different issue.
Cheers Johannes Am 19.02.19 um 19:53 schrieb Joe K: > Hi everybody, > > I have a very complex flowgraph that sometimes simply stops processing > receive samples. It doesn't crash, the transmit side of the flowgraph > is still fully operational. There are no exceptions being thrown and > nothing indicating that any threads are dying. > > This makes use of a lot of out-of-tree custom modules. I've seen > similar things in situations where I've screwed up in my OOT > modules--for example, if a sync block uses set_min_noutput_items with a > large value and the upstream block can only produce a small number of > samples, it seems possible to stall the flowgraph. > > The source is definitely not the cause of the stoppage--this happens > even in simulation where the input is just a noise source. It may take > hours of running for the flowgraph to stall. Or minutes. It seems very > random. > > My question is: are there any tools available to me to help determine > what's causing the stall? I've tried using GDB, which is difficult with > ~100 threads and it just seems that most things are at semaphore waits. > I don't know that I can deduce anything else from GDB. I really do > think it's ultimately a logical issue like what I previously described > where I'm mistreating the scheduler and giving it a situation it cannot > cope with. > > Basically, can I poke the scheduler and say "tell me what's going on"? > I'd love to get some data on the last several rounds of forecast() calls > and details on the work function calls, e.g., "Block such-and-such was > provided X inputs and space for Y outputs, it consumed A and produced B" > > Thanks! > > Joe > > _______________________________________________ > 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
