packet_transmitter_sdr fails because FileSink gets a very large inSpan.size()

[daniestevez]

This bug is easier to replicate when writing to /dev/null instead of a FIFO that goes to a GNU Radio 3.10 flowgraph.

Compiling with -DTRACE and running as ./examples/packet_transmitter_sdr /dev/null 1 | grep -v TunSource gives the following:

[...]
gr::packet_modem::PacketCounter<std::__1::complex<float>>::processBulk(inSpan.size() = 768, outSpan.size() = 768, countSpan.size() = 65535), _count = 1755
gr::packet_modem::PacketCounter<std::__1::complex<float>> incremented _count
gr::packet_modem::PduToTaggedStream<std::__1::complex<float>>::processBulk(inSpan.size() = 0, outSpan.size() = 64496, countSpan.size() = 63780), _index = 0, _packet_count = 1756
gr::packet_modem::InterpolatingFirFilter<std::__1::complex<float>, std::__1::complex<float>, float>::processBulk(inSpan.size() = 1040, outSpan.size = 4160)
gr::packet_modem::InterpolatingFirFilter<std::__1::complex<float>, std::__1::complex<float>, float> tags present: map = { packet_type: IDLE }
gr::packet_modem::FileSink<std::__1::complex<float>>::processBulk(inSpan.size() = 768)
gr::packet_modem::PacketCounter<std::__1::complex<float>>::processBulk(inSpan.size() = 4160, outSpan.size() = 4160, countSpan.size() = 65534), _count = 1756
gr::packet_modem::PduToTaggedStream<std::__1::complex<float>>::processBulk(inSpan.size() = 0, outSpan.size() = 65536, countSpan.size() = 63780), _index = 0, _packet_count = 1756
gr::packet_modem::FileSink<std::__1::complex<float>>::processBulk(inSpan.size() = 4160)
gr::packet_modem::PduToTaggedStream<std::__1::complex<float>>::processBulk(inSpan.size() = 0, outSpan.size() = 65536, countSpan.size() = 63780), _index = 0, _packet_count = 1756
gr::packet_modem::FileSink<std::__1::complex<float>>::processBulk(inSpan.size() = 18446744073700898048)
gr::packet_modem::FileSink<std::__1::complex<float>> fwrite failed: n = 18446744073700898048, ret = 256, errno = 0
[...]

After FileSink is called with inSpan.size() = 4160 (which is what the PacketCounter has produced immediately before), FileSink is called again with inSpan.size() = 18446744073700898048. This is completely wrong, and apparently happens even though PacketCounter (which is connected to the FileSink input) hasn't been called again. Note that 18446744073700898048 = 2**64 - 8653568.

[daniestevez]

The cause of this seems to be the same as #13:

ConsumableInputRange(.., 38912, 4160)
_buffer->_claimStrategy._publishCursor.value() = 7120960, _readIndexCached = 7116800, _readIndex->value() = 7116800
_buffer->_claimStrategy._publishCursor.value() = 7120960, _readIndexCached = 7116800, _readIndex->value() = 7116800
Writer::tryReserve(0), _offset = 7120960
WARNING: PublishableOutputRange(parent) setting _index and _offset to 0
PublishableOutputRange calling _claimStrategy.publish(0, 0)
_buffer->_claimStrategy._publishCursor.value() = 0, _readIndexCached = 7120960, _readIndex->value() = 7120960
getPortLimits() result.maxAvailable = 18446744073702430656, available = 18446744073702430656
gr::packet_modem::FileSink<std::__1::complex<float>>::workInternal() processedIn = 18446744073702430656, availableToProcess = 18446744073702430656, maxSyncAvailableIn = 18446744073702430656
ConsumablePortInputRange::get(18446744073702430656)

[daniestevez]

Probably this bug has been fixed by https://github.com/fair-acc/gnuradio4/pull/406. Closing.