I upgraded my machine to 2gb RAM and compiled MuseScore 3.6.2 from upstream source directly in the target machine. The resulting binary shows the splash screen and then segfaults very like the binary package.
From this exercise I conclude:
1. The problem is not memory starvation
2. The problem is not that packaged binary requires CPU flags most true 32-bit machines don't have simply because they were auto-detected on the machine that ran the build.
The obvious next step would be to build not only MuseScore but also its dependencies from source in case, for instance, some portion of Qt had been compiled using SSE3 instructions, but I think I'll let this rest for now and see if I can get it going on different hardware a different day.
Side note: MuseScore also bombs out on NetBSD on the Banana Pi BPI M2 Zero, which is an ARMv7 board. In that case several other graphical applications also bombed (lightweight parts of EDE running FLTK), making me wonder if they needed an X extension not available on that simple framebuffer or something.
Thanks,
Timothy
The following reply was made to PR pkg/57795; it has been noted by GNATS.
From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc:
Subject: Re: pkg/57795 (Musescore segfaults when loading home screen.)
Date: Fri, 05 Jan 2024 00:28:10 -0500
There's really not anything actionable from this report, the backtrace
is unusable. I tried to reproduce this using the most analogous
hardware I had (about four years newer), a netbook with an Atom N270
(1.6 GHz) processor, 1GB of RAM, etc. Unfortunately, I ran into mostly
or completely unrelated regressions between NetBSD 9.3 and 10.0 RC1 on
it (including that X would crash and in turn cause a kernel panic), and
didn't get far enough to actually try out the package there. I then
stood up 10.0 RC1 i386 in a VM (backed by an Intel Haswell CPU, 2GB of
RAM available), which successfully runs MuseScore without issue (e.g.,
editing a score). So this issue seems specific to the reporter's
hardware. I would point out it's problematic expecting a modern music
processor to run reliably on roughly twenty-year-old hardware that's
well below the minimum specs the upstream project quotes.
Dave