Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 384435

Summary: app-emulation/qemu-kvm-0.14.1-r2 => /usr/bin/qemu-system-x86_64: segfault
Product: Gentoo Linux Reporter: Dominik <dominiks.mail>
Component: Current packagesAssignee: Gentoo QEMU Project <qemu+disabled>
Status: RESOLVED DUPLICATE    
Severity: critical CC: nU1ya9bPIA
Priority: Normal    
Version: unspecified   
Hardware: x86   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Dominik 2011-09-25 14:44:10 UTC
After doing an upgrade to qemu-kvm-0.14.1-r2 the qemu-system-x86 binary run into segfault immediately after starting it.

# gdb /usr/bin/qemu-system-x86_64
GNU gdb (Gentoo 7.2 p1) 7.2
Reading symbols from /usr/bin/qemu-system-x86_64...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/qemu-system-x86_64
[Thread debugging using libthread_db enabled]
[New Thread 0xb7958b70 (LWP 12708)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7958b70 (LWP 12708)]
0xb7dd0bb5 in ?? ()



After compiling again with -C0 instead of -C2 the binary worked again and my virtual server is running again. So i think this maybe a general bug.

I'am using gcc-4.5.3 with the following make.conf

GENTOO_MIRRORS="http://de-mirror.org/distro/gentoo http://distfiles.gentoo.org"
CHOST="i686-pc-linux-gnu"
CFLAGS="-O2 -pipe -mtune=i686 -fomit-frame-pointer -fforce-addr"
CXXFLAGS="-O2 -pipe -mtune=i686 -fomit-frame-pointer -fforce-addr"
USE="-* acl bcmath bzip2 caps cgi crypt exif expat fam fastcgi ftp gd \
     gdbm gmp graphviz hardened iconv idn imap jpeg libwww mhash mime \
     mysql mysqli profiling nocxx nptl pcre perl pic png posix python \
     readline sasl session sockets spl sse ssl svg symlink tcl tcpd X \
     threads tiff tokenizer truetype unicode xattr xml xmlrpc xsl \
     zlib simplexml cli php_targets_php5-3 static-libs parted qemu \
     lvm device-mapper libvirtd virt-network lxc fontconfig lock_pthreadmutex hash"

LINGUAS="en de"
PHP_TARGETS="php5-3"
QEMU_SOFTMMU_TARGETS="i386 x86_64"
QEMU_USER_TARGETS="i386 x86_64"


Reproducible: Always

Steps to Reproduce:
1. Install Gentoo 32-bit
2. Use gcc-4.53 and make.conf above from Gentoo hardend and compile qemu-kvm-0.14.1-r2
3. Run /usr/bin/qemu-system-x86_64


Expected Results:  
Not run into segfault
Comment 1 steve 2011-10-13 00:59:01 UTC
I've run into the same issue (same segfault, and same eventual solution) except I tried a variety of other things that might help someone else figure out what's going on:

rolled back to qemu-kvm-0.13 (same issue)
rebuilt kernel & modules and rebooted -> (same issue)
[reinstalled 0.14.1-r2 since rollback didn't do anything different]

At this point I decided to rebuild the whole system (emerge -e --oneshot world), which hadn't been done for a few gcc versions as I recall, so I let it go, this had no affect either (to which I wasn't surprised).

While emerging the system I noticed that "qemu-system-x86_64 -no-kvm" would start & (and as far as I can tell) work, though I can't really test it legitimately since without hardware support my vm doesn't really work. This to me suggests the issue lies between qemu and GCC (but not a specific version of qemu, since my attempts to fall back to the older version made no difference). At this point I hadn't thought of/tried fiddling with -O options

I tried several times to build (using GCC 4.5.3-r1) qemu-kvm-0.14 with -O1, but it fails (somehow running out of memory during linking)

So I tried again (again using GCC 4.5.3-r1), but with -O0, and it built, and the resulting binary works.

I then built it using the normal -O2 flag and the previous hardened gcc version (4.4.5), which ALSO yeilds a working binary (I ended up using this one in the end because the current situation suggests that there might be something strange going on with gcc 4.5.3-r1)

Further notes: My system has USE=+hardened, but not with a hardened kernel, and is non-64bit, Core2 Q9550

I also kept the binaries (from /usr/bin/qemu*) of the broken -O2 builds from gcc4.5.3, as well as the working -O0 build from gcc4.5.3, and the working gcc4.4.5 build. I don't know enough about debugging this sort of thing to do anything with them (other than the observation that the broken binaries are smaller than their working counterparts)


If anyone wants the files let me know.
Comment 2 Doug Goldstein (RETIRED) gentoo-dev 2012-01-25 04:51:34 UTC
This actually looks a lot like bug #371453, can you retest with newer versions?

*** This bug has been marked as a duplicate of bug 371453 ***
Comment 3 Dominik 2012-02-18 12:22:36 UTC
version 0.15.1 released this week does work for me. Compiled with -O2