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

Package:
src:gupnp
Source:
src:gupnp
Submitter:
John David Anglin
Date:
2024-11-29 18:09:01 UTC
Severity:
normal
Tags:
#1044651#5
Date:
2023-08-13 17:29:47 UTC
From:
To:
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

#1044651#10
Date:
2024-11-26 21:32:33 UTC
From:
To:
Could it be a problem with the qemu emulation?
We have faced GIO issues with qemu in the past.

For now I switch the debian buildds to build that package on pyhsical hppa machines only.
That way we can see if it's qemu related...

Helge

#1044651#15
Date:
2024-11-27 11:14:52 UTC
From:
To:
That's a qemu issue.

This sockopt call is not implemented yet in qemu v9.2.0-rc1:
setsockopt(4, SOL_IP, IP_MULTICAST_IF, [16777343], 4) = 0

working on a qemu patch....

#1044651#20
Date:
2024-11-29 18:05:31 UTC
From:
To:
I posted the patches to fix this issue in qemu here:
https://lists.nongnu.org/archive/html/qemu-devel/2024-11/msg05466.html