1 files changed, 58 insertions, 0 deletions
diff --git a/mailinglist/output_launchpad/1221966 b/mailinglist/output_launchpad/1221966
new file mode 100644
index 00000000..5c78c1de
--- /dev/null
+++ b/mailinglist/output_launchpad/1221966
@@ -0,0 +1,58 @@
+SIGSEGV in static_code_gen_buffer
+
+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)
+
+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?
+
+
+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.
+
+"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.
+
+
+Oh is it?  Sorry, I guess I didn't understand what that function was doing.  That thing is sort of confusing in there...
+
+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.
+
+Triaging old bug tickets ... is this still an issue with the latest version of QEMU or could we close this ticket nowadays?
+
+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...
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+