Crash after grc window opens on ARM (M1) (BigSur)

[hexagonal-sun (Matthew Leach)]

Hi,

I've managed to get gnuradio built natively for the M1 chip. I used the variant:

-python37 +python38 -docs +quartz

Whenever I open gnuradio-companion after a few seconds it crashes; I've attached the crash repot. It doesn't look like gnuradio is a fault, however, grc is causing the crash and I'm unsure what component is at fault here (I presume it's either Python or GTK3).

If someone could point me to the correct place to raise the bug report that would be great!

Thanks, Matt

[hexagonal-sun (Matthew Leach)]

Crash report

[jmroot (Joshua Root)]

Be aware that only Python 3.9 has proper macOS 11 and arm64 support at this point (backport to 3.8 hasn't happened yet). Libffi also has some issues to be resolved in the next release.

[hexagonal-sun (Matthew Leach)]

Ah, great. Thanks for the info. Do you know if there is any plans for gnuradio to support python 3.9 any time soon?

[ra1nb0w]

I enabled the python 3.9 support on gnuradio 3.8. I don't know if it works fine therefore try it and then report here your experience. If everything works fine I will enable python 3.9 on all gr-* modules.

[hexagonal-sun (Matthew Leach)]

Thanks for enabling that. First issue I hit was that pyqtgraph didn't have support for python 3.9. I submitted a PR for this: ​https://github.com/macports/macports-ports/pull/9880. After this gnuradio successfully compiled. Unfortunetly, I'm still seeing crashes (see new crash log).

I'm unsure whether this is an issue with python or gtk? It looks like the crashing function is part of the gtk libraries (​https://developer.gnome.org/gi/stable/gi-girffi.html#g-callable-info-prepare-closure), I'm just not sure whether it's python calling it incorrectly.

[hexagonal-sun (Matthew Leach)]

After doing some reading, I think the issue is with pygobject. I've raised an issue upstream: ​https://gitlab.gnome.org/GNOME/pygobject/-/issues/455

[ra1nb0w]

Ok Feel free to report the status/changes here.

[michaelld (Michael Dickens)]

I have a vague memory that GR doesn't work with Py38 or newer yet. I think this was a change in Python's fork or spawn ... maybe I'm mis-remembering ... Either way thanks for moving GR along & reporting upstream!

[michaelld (Michael Dickens)]

The memory is that it's not GR but some dependency ... might pygobject ... which has been updated since I last investigated, but this might still be an issue there ...

[jmroot (Joshua Root)]

Gobject may also be hitting the libffi issues.

[michaelld (Michael Dickens)]

FYI this is still an issue: the gnuradio port with either +python38 or +python39 crashes in the same way. From ​the crash report noted above, it looks like the issue is with the GOI interface to libffi ... amazingly no comment from GOI devs!

[michaelld (Michael Dickens)]

This issue is being discussed here as well as on ​GNU Radio GitHub issue.

LIBFFI added a configure flag ​(--disable-exec-static-tramp) that should allow a workaround, but it is for Linux only and although we could patch the configure script to work with *darwin* it's not clear that it would do what the flag is intended for on Darwin.

There is a ​proposed fix to GOI, but since MacPorts' GOI is so old this won't help here much. Further, because this fix changes the GOI API, it's not clear whether it will even be accepted.

The best approach for MP's needs, in my opinion, is ​this proposed hack/fix to py-gobject3 that basically rewrites the underlying allocation / deallocation routines to work correctly with GOI and LIBFFI regardless of the CPU. Given that the issue seems to be coming up thus far just with the Python interface, which has to go through py-gobject3, this seems like a solid way to address it.

This fix is being considered upstream. In my initial testing, it does the trick to allow PyGobject3 to work on ARM64, and doesn't seem to hurt x86/x86_64. Given that we work primarily on macOS / OSX, this covers the gamut of CPUs we really care about (and, hopefully it also works on PPC/PPC64, but that's a secondary consideration ...).

[michaelld (Michael Dickens)]

PR: ​https://github.com/macports/macports-ports/pull/12377

[michaelld (Michael Dickens)]

In 36b3f88e0593140ae0f5639681f35a76b2a52c32/macports-ports (master):

py-gobject3: add patch to address closure / tramp on ARM64

NOTE: This patch is not official! It is a "best effort" workaround for the issue, and for the Python interface to GObject-Introspection only.

Closes: #62180