SIGSEGV in static_code_gen_buffer

[William D Colburn]

Trying to run 'ls' (or, anything else as far as I can tell) from a SunOS 5.8 box under RHEL 6.4 linux, I get a segfault. I've tried qemu-1.5.3, qemu-1.6.0, and I fetched git://git.qemu-project.org/qemu.git. I've also tried a statically linked sh from /sbin/ and it also segfaulted.

wcolburn@anotheruvula</home/anotheruvula/qemu>$ gdb bin/qemu-sparc
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/anotheruvula/qemu/bin/qemu-sparc...done.
(gdb) run ../sparc/ls
Starting program: /home/anotheruvula/qemu/bin/qemu-sparc ../sparc/ls
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff8259116 in static_code_gen_buffer ()
Missing separate debuginfos, use: debuginfo-install glib2-2.22.5-7.el6.x86_64 glibc-2.12-1.107.el6_4.4.x86_64
(gdb) where
#0 0x00007ffff8259116 in static_code_gen_buffer ()
#1 0x00007ffff7f570cd in cpu_tb_exec (cpu=0x7ffffa2b1210, tb_ptr=
    0x7ffff82590d0 "A\213n \205í\017\205Í")
    at /home/anotheruvula/qemu-devel/cpu-exec.c:56
#2 0x00007ffff7f57b2d in cpu_sparc_exec (env=0x7ffffa2b1348)
    at /home/anotheruvula/qemu-devel/cpu-exec.c:631
#3 0x00007ffff7f77f36 in cpu_loop (env=0x7ffffa2b1348)
    at /home/anotheruvula/qemu-devel/linux-user/main.c:1089
#4 0x00007ffff7f798ff in main (argc=2, argv=0x7fffffffdfc8, envp=
    0x7fffffffdfe0) at /home/anotheruvula/qemu-devel/linux-user/main.c:4083
(gdb)

[Peter Maydell (pmaydell)]

SIGSEGVs from qemu-linux-user are expected -- this is how we track self-modifying code in the guest binary. We catch the SIGSEGV and handle it appropriately. In particular, SPARC binaries do this a lot because their dynamic-linking mechanism involves self-modifying code.

If you don't run the program under a debugger (or if you tell gdb to pass SIGSEGV through to the target rather than stopping), what does it do?

[William D Colburn (wcolburn+launchpad)]

If I run it normally, it crashes in the same way. If I pass the signal through it crashes in the same way. I sort of expect this, since it is qemu segfaulting when it tries to generate the code buffer, not the underlying problem.

[Peter Maydell (pmaydell)]

"it is qemu segfaulting when it tries to generate the code buffer" -- why do you think this? The backtrace you quote shows the segfault inside static_code_gen_buffer(), which means we are running the generated code, not doing codegen.

[William D Colburn (wcolburn+launchpad)]

Oh is it? Sorry, I guess I didn't understand what that function was doing. That thing is sort of confusing in there...

[William D Colburn (wcolburn+launchpad)]

And, in the grand scheme of things, I've been trying to piece together what the problem software is that I need qemu for. It turns out I've got two very old sparcs both running Oracle with a variety of client programs I need. It could be that qemu-sparc is a waste of time and I need to focus on qemu-system-sparc instead.

If you want to "disappear" this bug, go ahead.

[Thomas Huth (th-huth)]

Triaging old bug tickets ... is this still an issue with the latest version of QEMU or could we close this ticket nowadays?

[Peter Maydell (pmaydell)]

Also I just noticed that the original report says the crash is while trying to run a SunOS binary. This isn't supported at all -- we can run Linux Sparc binaries with qemu-sparc, not random-other-OS binaries, and "guest binary crashes" is not an implausible result...

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]