Description of problem: qemu-i386 always crashes when started on i386 arch. Version-Release number of selected component (if applicable): qemu-0.9.0-2.fc7 How reproducible: Always. Steps to Reproduce: Just run qemu-i386 with any options. Actual results: Segmentation fault Additional info: Unfortunately I am unable to generate meaningful backtrace with symbols, but since it can be reproduced at will by anybody, this should not pose a problem, I hope.
I can confirm this, I can also confirm that running it under gdb to get a backtrace it useless, even with the debuginfo package installed. Something interesting in a strace: mprotect(0x80000000, 516096, PROT_READ|PROT_WRITE) = 0 mprotect(0x80000000, 516096, PROT_READ|PROT_EXEC) = 0 But the address 0x80000000 was never returned by any previous mmap or other syscall.
I tried to run this command in FC8 and it still segfaults. This time in a stacktrace I can see that it jumped to ip of 0 from somewhere in fprintf call. Happens on both x86_64 and i386 versions. Qemu version this time is qemu-0.9.0-5.fc8
Same here with qemu-0.9.0-5.fc8. When attempting to modprobe kqemu with kqemu-1.3.0-2.fc8 the modprobe hangs wasting all system resources and then killed by kernel on i386. Relevant strace: read(3, "odules/2.6.23.15-137.fc8/kernel/"..., 4096) = 4096 read(3, "ipv4/netfilter/arpt_mangle.ko: /"..., 4096) = 4096 read(3, "/net/dccp/dccp_ipv6.ko: /lib/mod"..., 4096) = 3793 close(3) = 0 munmap(0xb7f10000, 4096) = 0 open("/lib/modules/2.6.23.15-137.fc8/updates/kernel/kqemu.ko", O_RDWR) = 3 fcntl64(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=1}) = 0 open("/proc/modules", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f10000 read(4, "autofs4 20421 2 - Live 0xe0bb100"..., 1024) = 1024 read(4, "97_codec,snd_seq_oss,snd_seq,snd"..., 1024) = 885 read(4, "", 1024) = 0 close(4) = 0 munmap(0xb7f10000, 4096) = 0 close(3) = 0 rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0xbfafb044) = 5258 waitpid(5258, ... and of course: -bash-3.2# ps -A | grep 5258 5258 pts/0 00:00:00 modprobe
I've just compiled current svn (svn://svn.sv.gnu.org/qemu/trunk, revision 4414) for an i686. Problem seems to be fixed: $ i386-linux-user/qemu-i386 /bin/date qemu: Unsupported syscall: 240 Sat May 10 21:05:19 CEST 2008 As noted above (comment #2 and comment #3) qemu-0.9.0-7.fc8 still gives: $ qemu-i386 Segmentation fault So this seems to be either: - caused by the Red Hat/Fedora patches (unlikely?); - fixed in 0.9.1; - fixed in trunk. Further testing needed.
Now I've compiled 0.9.1 for an i686 (without the Red Hat/Fedora patches). Everything seems fine: $ usr/bin/qemu-i386 /bin/date qemu: Unsupported syscall: 240 Sat May 10 21:49:16 CEST 2008 So this is either: - caused by the Red Hat/Fedora patches; - a bug in 0.9.0 that was fixed in 0.9.1. To be continued.
And now I've compiled 0.9.0 for an i686 (without the Red Hat/Fedora patches). Segfaults also: $ usr/bin/qemu-i386 bin/date Segmentation fault So this should be a bug in 0.9.0 that was fixed in 0.9.1. Unless we want to get to the bottom of this, this bug might just as well be closed FIXED/UPSTREAM (or something similar).
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
$ cat /etc/fedora-release Fedora release 9 (Sulphur) $ rpm -q qemu qemu-0.9.1-5.fc9.i386 $ /usr/bin/qemu-i386 /bin/date qemu: Unsupported syscall: 240 Sun Jun 1 13:37:18 CEST 2008 Can this now be closed FIXED (or similar)?
(In reply to comment #8) > $ cat /etc/fedora-release > Fedora release 9 (Sulphur) > $ rpm -q qemu > qemu-0.9.1-5.fc9.i386 > $ /usr/bin/qemu-i386 /bin/date > qemu: Unsupported syscall: 240 > Sun Jun 1 13:37:18 CEST 2008 > > Can this now be closed FIXED (or similar)? Yes, confirmed fixed on F-9, so closing. Chris Lalancette