Hey Marcus, Happy to be back in the mix!
Thanks for the feedback! I went ahead and made a PR <https://github.com/gnuradio/gnuradio/pull/8029> with a fix that reuses the output buffer for multiple downstream edges, so the fanout hang is gone. I forked from main (wasn’t sure if main-3.10 was the right branch), and tested on 3.10.12.0 and main, and it seems solid. Please feel free to try it. I totally agree, if a use-case comes up for multiple replacements, we can revisit with a config option, but this seems save for now. Thanks again for the guidance! — Wael > On Jan 27, 2026, at 2:27 AM, Marcus Müller <[email protected]> wrote: > > Hi Wael! > > Great to see you here again :)! > > I'm honestly not too deep into the implementation side of the custom buffers, > but reading your email, I'd say, yes, that's a bug; I'd hence love to have > that as an issue on our issue tracker, unless you directly have a fix (which > you seem to do). > > I could technically see why in the presence of different accelerators and if > our dynamic flowgraph reconfiguration worked flawlessly, you might want to > exchange buffers multiple times – but not in practice. So, I'd say, go for > it. Worst case, someone says "no!! You can't do that, we need…", then you > rightfully say "But we need …", and then (and only then, I'd propose) we add > a configuration option to switch between behaviours. > > In the meantime, I'm trying to get the right eyes on this. Thank you so much! > > Best regards, > Marcus > > On 2026-01-26 8:08 PM, Wael Farah wrote: >> Hi all, >> I ran into something that looks like a bug in GNU Radio runtime related to >> custom buffers and fanout, and I wanted to sanity-check it with the list >> before opening an issue or PR. >> The scenario is roughly: >> * >> An upstream block with a default (host) output buffer >> * >> That output fans out to multiple downstream blocks >> * >> Each downstream block requires a custom buffer (e.g., CUDA buffers) >> In this case, it looks like |flat_flowgraph::connect_block_inputs()| >> <https://github.com/ >> gnuradio/gnuradio/blob/ec7a3239645162ffea1925e6f1e6e62bf1349d03/gnuradio-runtime/lib/ >> flat_flowgraph.cc%23L160> ends up calling |replace_buffer()| >> <https://github.com/gnuradio/ >> gnuradio/blob/ec7a3239645162ffea1925e6f1e6e62bf1349d03/gnuradio-runtime/lib/ >> flat_flowgraph.cc%23L220> once per downstream edge. This results in multiple >> custom buffers being allocated for the same output port, but only the last >> one actually remains connected to the upstream block. The earlier buffers >> become orphaned, and the corresponding downstream blocks stall waiting for >> data that never arrives. >> From what I can tell, the root cause is that the buffer type comparison uses >> the upstream block’s |output_signature()|, which is static and doesn’t >> reflect that |replace_buffer()| may already have been called by a previous >> fanout edge. So every subsequent edge still thinks it’s dealing with a >> default buffer and tries to replace it again. >> I put together a small fix that: >> * >> Checks whether an output buffer already exists >> * >> Compares the /actual buffer type/ against the signature >> * >> Reuses the existing custom buffer if it was already replaced by an >> earlier fanout edge >> With this change, all downstream custom-buffer blocks share the same buffer >> created by the first edge, and the flowgraph no longer hangs. I’ve tested >> this with flowgraphs where a host block (e.g., |analog.sig_source|) fans out >> to multiple custom blocks; before the fix it would hang, after it works as >> expected. >> I’m currently seeing this on GNURadio _v.3.10.12.0_ release, but I also >> checked the maint-3.10 branch where the same behavior still appears to be >> present. >> Before I go any further: >> Does this match others’ understanding of how buffer replacement is supposed >> to work in fanout scenarios? Is there a reason GNU Radio intentionally >> allows multiple | replace_buffer()| calls on the same output port? >> Happy to open an issue or PR if this is indeed unintended behavior. >> Thanks! >> Wael > >
