Bug#1044651: gupnp: FTBFS on hppa - memory corruption in test-bugs

[John David Anglin]

Source: gupnp
Version: 1.6.5-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

See following logs:
https://buildd.debian.org/status/fetch.php?pkg=gupnp&arch=hppa&ver=1.6.5-1&stamp=1691698780&raw=0
https://buildd.debian.org/status/fetch.php?pkg=gupnp&arch=hppa&ver=1.6.5-1&stamp=1691705820&raw=0

The test-bugs suffers from time dependent memory corruption. This causes
assertion and segmentation faults in g_memory_output_stream_steal_as_bytes().
For example,

# GLib-GIO-DEBUG: GSocketClient: Starting application layer connection
# GLib-GIO-DEBUG: GSocketClient: Connection successful!
# gupnp-control-point-DEBUG: Loading description document http://127.0.0.1:36708/1234.xml
not ok /bugs/bgo/690400 - GLib-GIO-FATAL-CRITICAL: g_memory_output_stream_steal_as_bytes: assertion 'G_IS_MEMORY_OUTPUT_STREAM (ostream)' failed
Bail out!

Thread 1 "test-bugs" received signal SIGTRAP, Trace/breakpoint trap.
__GI___libc_free (mem=<optimized out>) at malloc.c:3366
3366    malloc.c: No such file or directory.

The corruption is often the value 0x24242425. When ostream points
to this value, the evaluation of 'G_IS_MEMORY_OUTPUT_STREAM (ostream)'
results in a segmentation fault.  I added an additional assert to
g_memory_output_stream_steal_as_bytes() to detect this case:

# GLib-GIO-DEBUG: GSocketClient: Connection successful!
# gupnp-control-point-DEBUG: Loading description document http://127.0.0.1:38820/1234.xml
not ok /bugs/bgo/690400 - GLib-GIO-FATAL-CRITICAL: g_memory_output_stream_steal_as_bytes: assertion '(*(unsigned int *)ostream) != 0x24242424' failed
Bail out!

Thread 1 "test-bugs" received signal SIGTRAP, Trace/breakpoint trap.
__vasprintf_chk (result_ptr=0x53ec, flag=21484,
    format=0x5 <error: Cannot access memory at address 0x5>, ap=0x15421a01)
    at vasprintf_chk.c:36
36      vasprintf_chk.c: No such file or directory.

I'm not sure where the memory corruption is coming from. It might be
caused by loading the xml document. I tried using a watchpoint to detect
when the value changed to 0x24242424. It changed during a write syscall.
Splice doesn't seem involved and the write data string didn't contain
the '$' character. The watchpoint totally changes the execution timing,
so the write may not be involved.

The 0x24242424 corruption usally occurs in  /bugs/bgo/690400. The
'G_IS_MEMORY_OUTPUT_STREAM (ostream)' sometimes occurs in /bugs/bgo/678701:

# gupnp-control-point-DEBUG: Loading description document http://127.0.0.1:57666/1234.xml
# GLib-GIO-DEBUG: GSocketClient: Starting new address enumeration
# GLib-GIO-DEBUG: GSocketClient: Address enumeration succeeded
# GLib-GIO-DEBUG: GSocketClient: Starting TCP connection attempt
# GLib-GIO-DEBUG: GSocketClient: TCP connection successful
# GLib-GIO-DEBUG: GSocketClient: Starting application layer connection
# GLib-GIO-DEBUG: GSocketClient: Connection successful!
not ok /bugs/bgo/678701 - GLib-GIO-FATAL-CRITICAL: g_memory_output_stream_steal_as_bytes: assertion 'G_IS_MEMORY_OUTPUT_STREAM (ostream)' failed
Bail out!

Thread 1 "test-bugs" received signal SIGTRAP, Trace/breakpoint trap.
0x000000b4 in ?? ()

Regards,
Dave Anglin

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

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