qemu 4.0.0 broken by glib update

Bug #1838658 reported by Patrick Welche
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Unassigned

Bug Description

In brief, an install CD will successfully boot with qemu 4.0.0 built with glib 2.58.3, but freeze during boot with qemu 4.0.0 built with glib 2.60.0. I tracked it down to glib's GHashTable improvements. qemu is happy with a glib built from
```
 git checkout -f 2.60.4
 git revert --no-edit 86c6f7e2b..3bed8a13b
 git revert --no-edit 75f8ec1df9b48b0c3a13a9125f2c7d7c5adf5159
 git revert --no-edit 603fb5958..d3074a748
 git revert --no-edit 0b45ddc55..0600dd322
```
When the GHashTable improvements were committed, there was already a preemptive note about any breakage being due to using private implementation details, hence mentioning it here rather than with glib.

For the full saga, see: http://gnats.netbsd.org/54310

Revision history for this message
Daniel Berrange (berrange) wrote :

Fedora 30 has been shipping glib2 2.60.0 through to 2.60.5 and QEMU in general has been working normally AFAICT.

From the netbsd bug report it looks like the reproducer was demoed using the sparc emulator - is that the only QEMU arch that is affected ?

Revision history for this message
Daniel Berrange (berrange) wrote :
Download full text (5.2 KiB)

The test image that the netbsd bug points to no longer exists.

If I pick the image currently available:

  http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/images/NetBSD-9.99.2-sparc.iso

And launch it in a QEMU built from today's GIT master, on Fedora 30 with glib2 2.60.5, NetBSD successfully boots and launches the installer...

$ ~/usr/qemu-git/bin/qemu-system-sparc -drive file=NetBSD-9.99.2-sparc.img,format=raw,media=disk,snapshot=off -cdrom /var/lib/libvirt/images/NetBSD-9.99.2-sparc.iso -boot d -nographic
Configuration device id QEMU version 1 machine id 32
Probing SBus slot 0 offset 0
Probing SBus slot 1 offset 0
Probing SBus slot 2 offset 0
Probing SBus slot 3 offset 0
Probing SBus slot 4 offset 0
Probing SBus slot 5 offset 0
Invalid FCode start byte
CPUs: 1 x FMI,MB86904
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.1 built on Jul 1 2019 17:08
  Type 'help' for detailed information
Trying cdrom:d...
Not a bootable ELF image
Loading a.out image...
Loaded 65536 bytes
entry point is 0x4000
bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d
switching to new context:
>> NetBSD/sparc Secondary Boot, Revision 1.15 (Thu Aug 1 22:23:16 UTC 2019)
Booting netbsd
3375564+96668=0x34ffe0
OBP version 3, revision 2.25 (plugin rev 2)
[ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
[ 1.0000000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
[ 1.0000000] 2018, 2019 The NetBSD Foundation, Inc. All rights reserved.
[ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[ 1.0000000] The Regents of the University of California. All rights reserved.

[ 1.0000000] NetBSD 9.99.2 (INSTALL) #0: Thu Aug 1 22:23:16 UTC 2019
[ 1.0000000] <email address hidden>:/usr/src/sys/arch/sparc/compile/INSTALL
[ 1.0000000] total memory = 111 MB
[ 1.0000000] avail memory = 106 MB
[ 1.0000000] bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d
[ 1.0000000] mainbus0 (root): SUNW,SPARCstation-5: hostid 80123456
[ 1.0000000] cpu0 at mainbus0: FMI,MB86904 @ 170 MHz, MB86910 or WTL1164/5 FPU
[ 1.0000000] cpu0: 16K instruction (32 b/l), 8K data (16 b/l), 512K external (32 b/l): cache enabled
[ 1.0000000] obio0 at mainbus0
[ 1.0000000] clock0 at obio0 slot 0 offset 0x200000: mk48t08
[ 1.0000000] timer0 at obio0 slot 0 offset 0xd00000: delay constant 201, frequency = 2000000 Hz
[ 1.0000050] zs0 at obio0 slot 0 offset 0x100000 level 12 softpri 6
[ 1.0000050] zstty0 at zs0 channel 0 (console i/o)
[ 1.0000050] zstty1 at zs0 channel 1
[ 1.0000050] zs1 at obio0 slot 0 offset 0x0 level 12 softpri 6
[ 1.0000050] zstty2 at zs1 channel 0
[ 1.0000050] kbd0 at zstty2
[ 1.0000050] zstty3 at zs1 channel 1
[ 1.0000050] ms0 at zstty3
[ 1.0000050] wsmouse0 at ms0 mux 0
[ 1.0000050] fdc0 at obio0 slot 0 offset 0x400000 level 11 softpri 4: chip 82077
[ 1.0000050] fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
[ 1.0000050] auxreg0 at obio0 slot 0 offset 0x900000
[ 1.0000050] power0 at obio0 slot 0 offset 0x910000 level 2
[ 1.0000050] slavioconfig at obio0 slot 0 of...

Read more...

Revision history for this message
Andreas Gustafsson (gson) wrote :

> From the netbsd bug report it looks like the reproducer was demoed
> using the sparc emulator - is that the only QEMU arch that is affected ?

Only one arch is affected, but it's sparc64, not sparc.

Revision history for this message
Andreas Gustafsson (gson) wrote :

> The test image that the netbsd bug points to no longer exists.

Please try this one instead:

  https://www.gson.org/bugs/qemu/NetBSD-8.99.47-sparc64.iso

I just verified that this image works for reproducing the bug.

Revision history for this message
Daniel Berrange (berrange) wrote :

Doh, sorry for my comment earlier where I mistakenly used sparc instead of sparc64.

I've now tested QEMU git master with that sparc64 ISO and qemu-system-sparc64.

I still can't reproduce it though - it boots past the disk probing, and into the installer, where it asks for the terminal type.

So looks like there's some further variable involved beyond just the glib update - perhaps something about the host OS is combining with the glib update to trigger it.

Revision history for this message
Andreas Gustafsson (gson) wrote :

> So looks like there's some further variable involved beyond just the
> glib update - perhaps something about the host OS is combining with
> the glib update to trigger it.

Agreed - I just retested using a Fedora 30 instance on EC2, with
glib2-2.60.1-2.fc30.x86_64, and was also unable to reproduce the
issue there.

Revision history for this message
Peter Maydell (pmaydell) wrote :

The linked NetBSD bug report http://gnats.netbsd.org/54310 now has confirmation that this crash was the result of a memory corruption bug in QEMU which happened to manifest with the newer glib version. That bug is fixed in QEMU master in commit ef905eff421c5a06a01 which will be in the 5.2 release, so we can mark this as 'fix committed'.

Changed in qemu:
status: New → Fix Committed
Revision history for this message
Thomas Huth (th-huth) wrote :

Released with QEMU v5.2.0.

Changed in qemu:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.