Bug#1020321: glib2.0: FTBFS on hppa - test simple-construction1 fails

[Simon McVittie]

On Tue, 20 Sep 2022 at 00:16:04 +, 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=hppa=2.74.0-1=1663637461=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=hppa=2.74.0-1=1663629476=0
the test failed in the same way you reported.

smcv

Bug#1020321: glib2.0: FTBFS on hppa - test simple-construction1 fails

[John David Anglin]

Source: glib2.0
Version: 2.66.8-1
Severity: normal

Dear Maintainer,

Test fails as follows:

Running test simple-construction1

(performance:11828): GLib-ERROR **: 23:07:39.938: ../../../glib/gmem.c:430: over
flow allocating 2147483647*4 bytes
<80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95><80><95>
119/302 glib:gobject+performance / performance  FAIL
 7.18s   killed by signal 5 SIGTRAP

Full build log is here:
https://buildd.debian.org/status/fetch.php?pkg=glib2.0=hppa=2.74.0-1=1663629476=0

#define SIZE_OVERFLOWS(a,b) (G_UNLIKELY ((b) > 0 && (a) > G_MAXSIZE / (b)))

/**
 * g_realloc_n:
 * @mem: (nullable): the memory to reallocate
 * @n_blocks: the number of blocks to allocate
 * @n_block_bytes: the size of each block in bytes
 *
 * This function is similar to g_realloc(), allocating (@n_blocks * 
@n_block_bytes) bytes,
 * but care is taken to detect possible overflow during multiplication.
 *
 * If the allocation fails (because the system is out of memory),
 * the program is terminated.
 *
 * Since: 2.24
 * Returns: the new address of the allocated memory
 */
gpointer
g_realloc_n (gpointer mem,
 gsizen_blocks,
 gsizen_block_bytes)
{
  if (SIZE_OVERFLOWS (n_blocks, n_block_bytes))
{
  g_error ("%s: overflow allocating %"G_GSIZE_FORMAT"*%"G_GSIZE_FORMAT" 
bytes",
   G_STRLOC, n_blocks, n_block_bytes);
}

  return g_realloc (mem, n_blocks * n_block_bytes);
}

The 32-bit hppa runtime definitely can't handle an allocation of 8 GB.

Not sure why the test attempts to allocate this much. This test doesn't
fail on qemu buildds.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
merged-usr: no
Architecture: hppa (parisc64)

Kernel: Linux 5.19.9+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)