Re: Question about custom buffer handling with fanout (possible bug + fix)

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
> 
>