On Tue, 20 Sep 2022 at 00:16:04 +0000, John David Anglin wrote: > (performance:11828): GLib-ERROR **: 23:07:39.938: ../../../glib/gmem.c:430: > over > flow allocating 2147483647*4 bytes
Assuming hppa is 32-bit, that's an array of ((size_t) -1) 4-byte elements, so probably some uninitialized or incorrect number is being used as an array length. A backtrace from this crash (it's a SIGTRAP, so it should leave a core dump) will probably narrow down where to look. > Not sure why the test attempts to allocate this much. This test doesn't > fail on qemu buildds. This test succeeds on 32-bit release architectures like i386 and armhf, so there must be some hppa-specific reason why it's trying to use a nonsense array length. Is there something unusual about hppa memory layout or alignment or anything like that? In the buildd log at https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=hppa&ver=2.74.0-1&stamp=1663637461&raw=0 it doesn't seem to have DEB_BUILD_OPTIONS=nocheck, but also doesn't seem to be running tests at all? Has some toolchain package been modified to make it skip tests on this architecture, or something like that? In a previous buildd build https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=hppa&ver=2.74.0-1&stamp=1663629476&raw=0 the test failed in the same way you reported. smcv
