On 07/29/2012 05:18 PM, Avi Kivity wrote: > On 07/29/2012 05:03 PM, Chris Clayton wrote: >> On 07/29/12 13:42, Avi Kivity wrote: >>> On 07/27/2012 10:04 PM, Chris Clayton wrote: >>>> On 07/27/12 19:08, Eric Northup wrote: >>>>> Could you include the output of "info registers" at the point where it >>>>> crashed? >>>>> >>>> >>>> Here you go: >>>> >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to Thread 0xb6a78b40 (LWP 13249)] >>>> __strcmp_sse4_2 () at ../sysdeps/i386/i686/multiarch/strcmp-sse4.S:217 >>>> 217 movdqu (%edx), %xmm2 >>>> (gdb) bt >>>> #0 __strcmp_sse4_2 () at >>>> ../sysdeps/i386/i686/multiarch/strcmp-sse4.S:217 >>>> #1 0xb7e82cb4 in g_str_equal (v1=0x8a0cd58, v2=0x8319b82) at >>>> ghash.c:1704 >>>> #2 0xb7e8137a in g_hash_table_lookup_node (hash_table=0x89fe800, >>>> key=0x8319b82, hash_return=0xb6a78178) >>>> at ghash.c:422 >>>> #3 0xb7e821e5 in g_hash_table_lookup (hash_table=0x89fe800, >>>> key=key@entry=0x8319b82) at ghash.c:1074 >>>> #4 0x0815c9cb in type_table_lookup (name=0x8319b82 "apic-common") at >>>> qom/object.c:94 >>>> #5 type_get_by_name (name=name@entry=0x8319b82 "apic-common") at >>>> qom/object.c:149 >>>> #6 0x0815cf93 in object_dynamic_cast (obj=obj@entry=0x8a313e0, >>>> typename=typename@entry=0x8319b82 "apic-common") >>>> at qom/object.c:416 >>>> #7 0x0815cf2d in object_dynamic_cast_assert (obj=obj@entry=0x8a313e0, >>>> typename=typename@entry=0x8319b82 "apic-common") at >>>> qom/object.c:478 >>>> #8 0x08192c1b in cpu_set_apic_tpr (d=0x8a313e0, val=13 '\r') >>>> at /home/chris/rpm/BUILD/qemu-kvm-1.1.1/hw/apic_common.c:60 >>>> #9 0x081cb86c in kvm_arch_post_run (env=env@entry=0x8a29370, >>>> run=run@entry=0xb6274000) >>>> at /home/chris/rpm/BUILD/qemu-kvm-1.1.1/target-i386/kvm.c:1695 >>>> #10 0x081c686f in kvm_cpu_exec (env=env@entry=0x8a29370) at >>>> /home/chris/rpm/BUILD/qemu-kvm-1.1.1/kvm-all.c:1269 >>>> #11 0x08198c72 in qemu_kvm_cpu_thread_fn (arg=0x8a29370) at >>>> /home/chris/rpm/BUILD/qemu-kvm-1.1.1/cpus.c:752 >>>> #12 0xb7a3ed9e in start_thread () from /lib/libpthread.so.0 >>>> #13 0xb77e45ee in clone () at >>>> ../sysdeps/unix/sysv/linux/i386/clone.S:132 >>>> (gdb) info registers >>>> eax 0x8319b82 137468802 >>>> ecx 0xd58 3416 >>>> edx 0x8a0cd58 144756056 >>>> ebx 0xb7f7f2c4 -1208487228 >>>> esp 0xb6a780ec 0xb6a780ec >>>> ebp 0xb6a78118 0xb6a78118 >>>> esi 0x8a313e0 144905184 >>>> edi 0xc513 50451 >>>> eip 0xb7824f77 0xb7824f77 <__strcmp_sse4_2+23> >>>> eflags 0x10283 [ CF SF IF RF ] >>>> cs 0x73 115 >>>> ss 0x7b 123 >>>> ds 0x0 0 >>>> es 0x0 0 >>>> fs 0x0 0 >>>> gs 0x33 51 >>>> >>> >>> ds shouldn't be zero for a 32-bit process. >>> >>> But that should have crashed *much* earlier, ds is accessed all the time. >>> >>> Please add the following snippet to the beginning of kvm_arch_post_run(): >>> >>> { >>> unsigned short ds; >>> asm("mov %%ds, %0" : "=rm"(ds)); >>> assert(ds != 0); >>> } >>> >>> if the assert triggers, then kvm corrupted the segment registers. If >>> not, corruption happens somewhere above. >>> >> Thanks, Avi. >> >> The assert didn't trigger - I got: >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0xb60ffb40 (LWP 2134)] >> __strcmp_sse4_2 () at ../sysdeps/i386/i686/multiarch/strcmp-sse4.S:217 >> 217 movdqu (%edx), %xmm2 >> (gdb) info registers >> eax 0x8319ba2 137468834 >> ecx 0xd58 3416 >> edx 0x8a0cd58 144756056 >> ebx 0xb7f7f2c4 -1208487228 >> esp 0xb60ff0ec 0xb60ff0ec >> ebp 0xb60ff118 0xb60ff118 >> esi 0x8a44818 144984088 >> edi 0xc513 50451 >> eip 0xb7820f77 0xb7820f77 <__strcmp_sse4_2+23> >> eflags 0x10283 [ CF SF IF RF ] >> cs 0x73 115 >> ss 0x7b 123 >> ds 0x0 0 >> es 0x0 0 >> fs 0x0 0 >> gs 0x33 51 >> (gdb) list >> 212 #endif >> 213 mov %dx, %cx >> 214 and $0xfff, %cx >> 215 cmp $0xff0, %cx >> 216 ja L(first4bytes) >> 217 movdqu (%edx), %xmm2 >> 218 mov %eax, %ecx >> 219 and $0xfff, %ecx >> 220 cmp $0xff0, %ecx >> 221 ja L(first4bytes) >> (gdb) bt >> #0 __strcmp_sse4_2 () at ../sysdeps/i386/i686/multiarch/strcmp-sse4.S:217 >> #1 0xb7e82cb4 in g_str_equal (v1=0x8a0cd58, v2=0x8319ba2) at ghash.c:1704 >> #2 0xb7e8137a in g_hash_table_lookup_node (hash_table=0x89fe800, >> key=0x8319ba2, hash_return=0xb60ff178) >> at ghash.c:422 >> #3 0xb7e821e5 in g_hash_table_lookup (hash_table=0x89fe800, >> key=key@entry=0x8319ba2) at ghash.c:1074 >> #4 0x0815c9cb in type_table_lookup (name=0x8319ba2 "apic-common") at >> qom/object.c:94 >> #5 type_get_by_name (name=name@entry=0x8319ba2 "apic-common") at >> qom/object.c:149 >> #6 0x0815cf93 in object_dynamic_cast (obj=obj@entry=0x8a44818, >> typename=typename@entry=0x8319ba2 "apic-common") >> at qom/object.c:416 >> #7 0x0815cf2d in object_dynamic_cast_assert (obj=obj@entry=0x8a44818, >> typename=typename@entry=0x8319ba2 "apic-common") at qom/object.c:478 >> #8 0x08192c1b in cpu_set_apic_tpr (d=0x8a44818, val=7 '\a') >> at /home/chris/rpm/BUILD/qemu-kvm-1.1.1/hw/apic_common.c:60 >> #9 0x081cb874 in kvm_arch_post_run (env=env@entry=0x8a3ca60, >> run=run@entry=0xb626d000) >> at /home/chris/rpm/BUILD/qemu-kvm-1.1.1/target-i386/kvm.c:1702 >> #10 0x081c686f in kvm_cpu_exec (env=env@entry=0x8a3ca60) at >> /home/chris/rpm/BUILD/qemu-kvm-1.1.1/kvm-all.c:1269 >> #11 0x08198c72 in qemu_kvm_cpu_thread_fn (arg=0x8a3ca60) at >> /home/chris/rpm/BUILD/qemu-kvm-1.1.1/cpus.c:752 >> #12 0xb7a3ad9e in start_thread () from /lib/libpthread.so.0 >> #13 0xb77e05ee in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:132 >> >> I think you are saying that the problem isn't in kvm, so where would you >> recommend I continue investigations. I'm not seeing a crash with any >> other applications. > > What might have happened is that the movdqu instruction faulted (as it's > an fpu instruction), and on the way back from the fault, ds and es > didn't get restored correctly. > > You can test this by writing a trivial version of g_str_equal() > somewhere in the qemu source code and rebuilding it. > > from entry_32.S: .macro RESTORE_REGS pop=0 RESTORE_INT_REGS 1: popl_cfi %ds /*CFI_RESTORE ds;*/ 2: popl_cfi %es /*CFI_RESTORE es;*/ 3: popl_cfi %fs /*CFI_RESTORE fs;*/ POP_GS \pop .pushsection .fixup, "ax" 4: movl $0, (%esp) jmp 1b 5: movl $0, (%esp) jmp 2b 6: movl $0, (%esp) jmp 3b .popsection this piece of code tries to restore %ds, and if it fails, zeros it, which is consistent with the core dump. This could happen if kvm is failing to restore GDT correctly. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html