Cross compiling `mutter` 46 for `armv7` on a `x86_64` host fails with the following error below. Building `mutter-45` for `armv7` (e.g. `mutter-mobile` currently in pmaports) succeeds, but I suspect `mutter-mobile` will fail too once gnome-mobile is updated to work with mutter 46. ``` (process:56814): GLib-GObject-CRITICAL **: 18:33:05.900: validate_pspec_to_install: assertion 'G_IS_PARAM_SPEC (pspec)' failed (process:56814): GLib-GObject-CRITICAL **: 18:33:05.901: g_param_spec_ref_sink: assertion 'G_IS_PARAM_SPEC (pspec)' failed (process:56814): GLib-GObject-CRITICAL **: 18:33:05.901: g_param_spec_unref: assertion 'G_IS_PARAM_SPEC (pspec)' failed qemu: uncaught target signal 11 (Segmentation fault) - core dumped Command '['/home/pmos/build/src/mutter-46.1/output/tmp-introspectxw53akjt/Clutter-14', '--introspect-dump=/home/pmos/build/src/mutter-46.1/output/tmp-introspectxw53akjt/functions.txt,/home/pmos/build/src/mutter-46.1/output/tmp-introspectxw53akjt/dump.xml']' died with <Signals.SIGSEGV: 11>. ``` The actual failure is here: ``` [768/774] Generating clutter/clutter/Cally-14.gir with a custom command (wrapped by meson to set env) ``` I've been able to simplify reproducing it a bit by setting `GI_SCANNER_DEBUG="save-temps"` in `mutter/APKBUILD`, this lets us keep the tmp dir for `g-ir-scanner` (which seems to be failing AFAIK), and the failure can be quickly reproduced again after that by: 1) enter the chroot: `pmbootstrap chroot -b armv7` 2) `su pmos`, then `cd /home/pmos/build/src/mutter-46.1/output` (exact path from error message) 3) `tmp-introspectxw53akjt/Clutter-14 --introspect-dump=tmp-introspectxw53akjt/functions.txt,tmp-introspectxw53akjt/dump.xml` --> sigsegv I'm unable to run it with gdb (something about ptrace not available?)... ``` Starting program: tmp-introspectxw53akjt/Clutter-14 --introspect-dump=tmp-introspectxw53akjt/functions.txt,tmp-introspectxw53akjt/dump.xml warning: Could not trace the inferior process. warning: ptrace: Function not implemented During startup program exited with code 127. ``` When it fails under qemu-arm on x86_64, there's a message about qemu core dumping, but I haven't been able to figure out where this coredump is located: `qemu: uncaught target signal 11 (Segmentation fault) - core dumped` Running it with valgrind shows that it goes off the rails when it tries to access memory at `0x4`(?!). There are lots of "invalid write of size 4 errors" before this happens. ``` ... ==2802== Invalid write of size 4 ==2802== at 0x49C10BE: ??? (in /usr/lib/libglib-2.0.so.0.8000.2) ==2802== Address 0x3f8008a0 is on thread 1's stack ==2802== 16 bytes below stack pointer ==2802== (process:2802): GLib-GObject-CRITICAL **: 01:15:55.221: g_param_spec_double: assertion 'default_value >= minimum && default_value <= maximum' failed (process:2802): GLib-GObject-CRITICAL **: 01:15:55.507: validate_pspec_to_install: assertion 'G_IS_PARAM_SPEC (pspec)' failed (process:2802): GLib-GObject-CRITICAL **: 01:15:55.529: g_param_spec_ref_sink: assertion 'G_IS_PARAM_SPEC (pspec)' failed ==2802== Invalid write of size 4 ==2802== at 0x4974AD2: g_param_spec_unref (in /usr/lib/libgobject-2.0.so.0.8000.2) ==2802== Address 0x3f800b40 is on thread 1's stack ==2802== 8 bytes below stack pointer ==2802== (process:2802): GLib-GObject-CRITICAL **: 01:15:55.541: g_param_spec_unref: assertion 'G_IS_PARAM_SPEC (pspec)' failed ==2802== Invalid read of size 4 ==2802== at 0x4970254: g_object_class_install_properties (in /usr/lib/libgobject-2.0.so.0.8000.2) ==2802== Address 0x4 is not stack'd, malloc'd or (recently) free'd ==2802== ==2802== ==2802== Process terminating with default action of signal 11 (SIGSEGV) ==2802== Access not within mapped region at address 0x4 ==2802== at 0x4970254: g_object_class_install_properties (in /usr/lib/libgobject-2.0.so.0.8000.2) ``` Mutter builds successfully for armv7 on x86_64 if crossdirect is disabled. For more info, see https://gitlab.postmarketos.org/postmarketos/pmaports/-/merge_requests/5115#note_1899890119