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

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() ends up calling replace_buffer() 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