QT Gui Frequency Sink shows no output

[nvdomidi]

Dear dev team,

Upon adding a "QT Gui Frequency Sink" node, I get no output from executing the graph. All it says in the bottom left corner is " Done (return code 3221225501). I have tried running the code via conda prompt & ipython (as suggested in here), but I get nothing printed out in the terminal. I am using a windows 10 64 bit system.

Thanks in advance

[ryanvolz]

As with #10, I'm still at a loss for what is going wrong here since I can't reproduce it. Can you think of anything about your system or setup that might be rare relative to typical users?

One thought is that this could be related to the fact that the Qt GUI Frequency Sink calculates an FFT and the Time Sink doesn't. Are you able to use the FFT block? Try something like the example flowgraph there, but without the Frequency Sink.

[nvdomidi]

Dear Ryan

I have added an FFT Block and I still get the same error. 
Here is what happens: After installing GNU Radio on my windows 10 and running a system with a "QT GUI Freq Sink" block I get the following message: 

"The xterm executable 'xterm' is missing. You can change this setting in your gnuradio.conf, in section [grc],  'xterm_executable'.  (this message is shown only once)"

and I receive:  Done (return code 3221225501) message in the output LOG. 

Using FFT Block results in the same error as with "QT GUI Freq Sink".

However, if I remove the "QT GUI Freq Sink" block, and just use "QT GUI Time Sink" it works fine and shows the graph in a new window.

The following is the content of grc.conf which says xterm_missing = xterm and I think this needs to be fixed somehow.

Thank you for your help in advance.

---

This contains only GUI settings for GRC and is not meant for users to edit.

GRC settings not accessible through the GUI are in config.conf under section [grc].

[main]
xterm_missing = xterm
file_open = D:\GNURadio\SinewaveGRC.grc
main_window_width = 1360
main_window_height = 691
console_window_position = 507
blocks_window_position = 1165
variable_editor_position = 308

[files_open]
files_open_0 = D:\GNURadio\SinewaveGRC.grc

[files_recent]
files_recent_0 = D:\GNURadio\SinewaveGRC.grc

[olafk1]

Yesterday I got the same problem. It turns out that fft_filter_ccc crashes the python interpreter, which is inline with Ryan's hypothesis in #25 (comment) that probably FFT is involved. The crash is reproducible with a simple line like this:

python -c "from gnuradio import filter;filter.fft_filter_ccc(1, [1], 1)"

Further investigation showed that the code stops inside fftw-3.3.10 with an AVX instruction, which my old CPU does not support (although the conda-forge fftw build script suggests that SSE2 support should still be built in?!).

As a quick workaround (and prove of concept) I manually replaced fftw3.dll and fftw3f.dll with the ones from fftw-3.3.9 and all problems were gone.

So this looks like my hardware is completely outdated or there is a major build issue with the conda-forge fftw-3.3.10 package on Windows.

[ryanvolz]

Thanks for the detective work @olafk1! It does look like your CPU not supporting AVX is what causes the crash. The reason fftw 3.3.9 works but 3.3.10 doesn't, despite the build script supposedly enabling AVX and SSE2 for both, is that the Azure build machine from the older 3.3.9 build didn't support and therefore build AVX but the newer one does (although still not SSE2).

I'm not sure how to handle this going forward. It would seem that requiring AVX support leaves at least some users behind (you!), and maybe that's enough to get the fftw package maintainers to back off on that requirement. Maybe there's a way to support both. How old of a CPU are we talking about here?

[ryanvolz]

Supposedly fftw should be doing runtime detection and dispatch of AVX instructions, so I guess that's not working. More digging to do.

[olafk1]

I could put an upgrade to my Core i5 on my upcoming X-mas wish list. Unfortunately the story is a bit more complicated than that, because there is not only AVX, but also AVX2, AVX-512 not to forget MMX, SSE, SSE2, SSE3, SSE4, who knows... The dynamic decision of the perfect computation strategy on top of this hell of instruction variants is already part of fftw's DNA. This takes various factors into account (CPU-type, data type, size, ...) and the strategy is chosen at runtime (see also fftw_wisdom). Imho, as long as SSE2 support is their number one bullet point on the advertised list of features it should be compiled in. Therefore, this remains a conda-forge issue. Unfortunately, I couldn’t find the entry point on their website to raise a bug to the fftw maintainers. Fun fact: a look into the Windows fftw-3.3.10 binaries reveals that the version string is actually "fftw-3.3.9-avx" - even the numbers don’t match (btw. the Linux binaries correctly state "fftw-3.3.10-sse2-avx". This is a CMake vs. Configure thing on the fftw sources themselves, argggh). So there is definitely something rotten in the state of the fftw-3.3.10 build on Windows since mostly one year. On the Azure side I only noticed a change from vs2017 to vs2019, the respective compiler switches have not changed since more than a decade. I think we can close this issue here.

[ryanvolz]

We can leave the issue open to track when radioconda gets whatever fix is needed for the fftw package.

[olafk1]

Addendum: I should follow my own hints. A deeper look into CMakeList.txt of fftw shows more bugs than just the version lapse. The fftw developers accidentally dropped SSE2 support, as you can see in the diff here. One should know that MSVC (since VS 2015) supports the /arch:SSE2 compiler switch only on 32-bit compilers. The 64-bit compilers have removed this switch because there is no 64-bit CPU without SSE2 instructions, which means that SSE2 is already the default minimum architecture.

But with fftw-3.3.10 the CMake statement unset (HAVE_SSE2) was added to the compiler detection phase. Since /arch:SSE2 is now the default and is rejected by the 64-bit compiler, the HAVE_SSE2 flag is never set again even though the build script requests it explicitly.

Long story short: SSE2 code is omitted from the DLLs because(!) it is the default instruction set of the CPU; weird. That would mean that conda-forge and radioconda are just victims. I'll bet 50 cents that the root cause is this September 2021 fftw change in coincidence with some unforeseen behavior of 64-bit MSVC that simply rejects a redundant compiler switch (rather than ignoring it). I'll try to get in touch with them.

[ryanvolz]

Ugh, I forgot to push for a conda-forge fix for this before the latest radioconda release. @olafk1 is there a patch or change in the build script that you would recommend to fix the conda-forge fftw package absent a response from the upstream developers? I can put in a PR to the fftw-feedstock or support one that you create.

[olafk1]

I created a follow-up ticket with a tiny solution proposal here: FFTW/fftw3#292.

That ticket addresses a major performance flaw in MSVC non-AVX builds for 64-bit systems, which I also thought is responsible for the problem that brought us here. Unfortunately I was wrong. The patch would help us only as long as AVX is disabled, which would be an unacceptable degradation for all modern CPUs. This is not a solution for multipurpose builds like that from conda-forge.

Trying to fix this, I stumbled deeper and deeper into more conceptual problems of the FFTW build process. I succeeded with a trivial patch for SSE2+AVX that perfectly matched the cmake-build from conda-forge. Stupidly, I did more testing and identified that this patch would again be insufficient because it would only postpone the problem until we start enabling AVX2 instructions. Arrggh. But it seems as if I have now a solution for that issue as well. Btw, testing is a night mare and took forever until I discovered how to automate that using some special Intel tooling (http://www.intel.com/software/sde). This is part of all the delays.

Regarding your proposals: I like the idea to fix the root cause and avoid patching satellite builds, because after a small amount of time nobody from conda-forge would understand why and how this patch was introduced and even more important, how to maintain it. On the other hand I have no clue if there will be any response for change proposals on github.com/fftw not following a proper PR and/or parallel notification on their feedback channel ([email protected]).

So, I would trust your expertise on whether pushing the change through conda-forge to fix the root cause might be more promising than me posting troll comments on github.com/fftw. Any support from your side is appreciated. After implementing the patch (regardless of how), I would at least propose taking the chance to now include AVX2 support in the conda-forge build. Finally, this would help both owners of legacy CPUs as well as those with cutting-edge technology (although the gain might be less than 20% in the latter case).

Give me a day or two to complete my testing and submit the final ticket on github.com/fftw. The only remaining fear is that the patch will end up being ridiculously tiny. I will leave a notification here.

[ryanvolz]

I made a test build of fftw that force-enables SSL2 support. Find it here. From a radioconda prompt, you can run

mamba install https://anaconda.org/ryanvolz/fftw/3.3.10/download/win-64/fftw-3.3.10-nompi_ha5643a9_105.tar.bz2

Let me know if this fixes the issue, and if it doesn't then we'll know that the problem is more complex.

[ryanvolz]

Bumping this as a reminder to test the package linked in my last comment if you can. I'd like to know if it works so I know whether or not to propose the change to the conda-forge fftw package.

[ryanvolz]

Conda-forge is now shipping the updated version of the fftw package that actually builds SSE2 support for Windows. You should be able to upgrade with mamba upgrade fftw. Let me know if that fixes this issue.

[Randy-github]

I'm having a similar issue. I have a working flowgraph that was developed on a windows 10 box but it will no work on a windows 11 box. I've reduced the flowgraph to find that when either an fft filter or qt gui frequency sink block is enabled, I get a crash message similar to the OP. Searching that crash message was what lead me to this thread.

Both installations of gnuradio are on systems that didn't have it installed previously. I found and used the windows installer for radioconda 2022.09.22 then performed the upgrade with mamba upgrade --all.
I like this option too, btw. I was actually looking for the latest gnuradio package to install on a linux vm and ran across it. Very nicely done!

Aside from the windows 10 to 11 difference, the windows 10 box uses an intel Xeon processor while the windows 11 (mini form factor computer) uses a Celeron N5101. Reading this thread seems like this could be a similar issue. Double-checking, this is installed:
Name Version Build Channel
fftw 3.3.10 nompi_h38027f0_106 conda-forge

This Celeron has SSE and SSE2 instruction support but apparently no AVX.

Can you offer any suggestions? Thanks!

[ryanvolz]

@Randy-github Thanks for the report. That confirms that the latest fftw package, which should actually be built with SSE2 support for the first time, still doesn't solve the crash caused by a machine lacking AVX support. I have to wonder at this point if that isn't an upstream bug in fftw. We'll have to do more investigation.

[Randy-github]

@Randy-github Thanks for the report. That confirms that the latest fftw package, which should actually be built with SSE2 support for the first time, still doesn't solve the crash caused by a machine lacking AVX support. I have to wonder at this point if that isn't an upstream bug in fftw. We'll have to do more investigation.

Hello Ryan, just wondering if you've found anything on this yet.

If not, are you building the fftw package or getting a binary from someplace else? If you're building, can you point me to the build script? I'm trying to find the compiler settings used.

Thanks,
Randy

[ryanvolz]

I haven't been able to poke around at this yet.

The packages are built for conda-forge using the recipe in the feedstock repository. The build script in particular can be seen here.

[ryanvolz]

I think I have finally figured out what was wrong with fftw on Windows! Could anyone still having issues try to install this rebuilt package? From a radioconda prompt, you can run

mamba install https://anaconda.org/ryanvolz/fftw/3.3.10/download/win-64/fftw-3.3.10-nompi_h5648b18_107.conda

Let me know if this fixes things. Thanks!

[ryanvolz]

The updated fftw package is available through conda-forge now, so mamba upgrade fftw should be all that is needed to test it. I think this fixes the issue. If anyone still sees this after upgrading to fftw-3.3.10-nompi_h38027f0_107 or later (i.e. higher version number or build number 107 or higher), feel free to re-open. That version of fftw will be in the next installer release, soon.