More details.
I built GR with "cmake ../ -DPYTHON_EXECUTABLE=/usr/bin/python3 -DENABLE_DEFAULT=OFF -DENABLE_GNURADIO_RUNTIME=ON -DENABLE_PYTHON=ON -DENABLE_POSTINSTALL=OFF -DENABLE_DOXYGEN=OFF" in order to have the minimal build possible that reproduces the issue, and used the attached flowgraph. It's the same one as before, but I replaced Null Source with my_null_source (a Python implementation) in order to get rid of gnuradio-blocks (for speedier builds).
I don't understand why, but it seems that v3.7.8.2 is still ok, the bug starts at git commit 1206251231696359270a260508551e044f3af33a and breaks all versions from v3.7.9 to 3.7.11.0, then git commit 713629cce8d571570bc5f0f0db67c5a96d5ee071 seems to have fixed it in 3.7.12.0 and the rest of 3.7.* releases. The breaking commit is in the 3.8 history because the merge from next that came from 3.7.12.0 broke it again.
I will be happy if as a first step, someone will be able to confirm my findings:
- a06420691493534ca268ce52e1f16504c216828d is ok, but the next commit 1206251231696359270a260508551e044f3af33a is broken (confirming the issue in old 3.7 releases and 3.8).
- e635ae442132a7e3bab75796d2ac0b66bd289bdb is broken, but the next commit 713629cce8d571570bc5f0f0db67c5a96d5ee071 is ok (confirming the fix in the 3.7 history).
As a second step, can someone understand why the breaking commit broke and why the fixing commit fixed, and then apply the fixing logic on master?
Analyzing a non-linear history is some dirty work :)
How searching for the breaking commit in 3.8's history looks like: