Opened 3 years ago

Closed 2 years ago

#62180 closed defect (fixed)

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

Reported by: hexagonal-sun (Matthew Leach) Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: ra1nb0w
Port: gnuradio

Description

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

Attachments (2)

grc-crash-report.txt (11.7 KB) - added by hexagonal-sun (Matthew Leach) 3 years ago.
Crash report
crash-report-python39.txt (11.3 KB) - added by hexagonal-sun (Matthew Leach) 3 years ago.

Download all attachments as: .zip

Change History (15)

Changed 3 years ago by hexagonal-sun (Matthew Leach)

Attachment: grc-crash-report.txt added

Crash report

comment:1 Changed 3 years ago by jmroot (Joshua Root)

Cc: ra1nb0w added
Owner: set to michaelld
Status: newassigned

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.

comment:2 Changed 3 years ago by 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?

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by 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.

Changed 3 years ago by hexagonal-sun (Matthew Leach)

Attachment: crash-report-python39.txt added

comment:5 Changed 3 years ago by 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

comment:6 Changed 3 years ago by ra1nb0w

Ok Feel free to report the status/changes here.

comment:7 Changed 3 years ago by 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!

Last edited 3 years ago by michaelld (Michael Dickens) (previous) (diff)

comment:8 Changed 3 years ago by 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 ...

comment:9 Changed 3 years ago by jmroot (Joshua Root)

Gobject may also be hitting the libffi issues.

comment:10 Changed 3 years ago by 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!

comment:11 Changed 3 years ago by 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 ...).

comment:13 Changed 2 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.