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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
