Re: qemu-kvm-1.1.0 crashing with kernel 3.5.0-rc6

[Chris Clayton <chris2553@googlemail.com>]

On 07/26/12 13:07, Avi Kivity wrote:
> On 07/26/2012 02:58 PM, Chris Clayton wrote:
>
>>> It looks like general memory corruption.  Is this repeatable?  What's
>>> the guest uptime when it happens (i.e. is it immediate?)
>>
>> I've just done 10 runs of WinXP SP3 and 5 of them crashed. Three crashed
>> early as XP was starting up - well before the desktop would have
>> appeared. The other two crashed as XP was closing down, having been
>> running for a few minutes (but not doing much).
>>
>> The error messages seen through dmesg are:
>>
>> qemu-kvm[12778] general protection ip:b6c43d77 sp:b5e800fc error:0 in
>> libc-2.16.so[b6b06000+1b4000]
>> qemu-kvm[12813] general protection ip:b6bf6d77 sp:b54ff0fc error:0 in
>> libc-2.16.so[b6ab9000+1b4000]
>> qemu-kvm[12986] general protection ip:b6cd3d77 sp:b55ff0fc error:0 in
>> libc-2.16.so[b6b96000+1b4000]
>> qemu-kvm[13045] general protection ip:b6c91d77 sp:b54ff0fc error:0 in
>> libc-2.16.so[b6b54000+1b4000]
>> qemu-kvm[13225] general protection ip:b6c5bd77 sp:b54ff0fc error:0 in
>> libc-2.16.so[b6b1e000+1b4000]
>>
>> The other 5 were OK, although I only did a bit of web browsing for  few
>> minutes with IE.
>
> Failures always in the same place (I'm guess the variations are due to
> PIE -- please configure with --disable-pie for future tests).
>
> Please generate a core and look around, esp. in frame 3
> (type_table_lookup).  Also try to dissect type_table (you may need to
> install the glib debug symbols for this).
>
>
>
Mmm, I'm sailing out of my comfort zone here, but I've built a debug 
version of glib and trapped another crash. The backtrace is:

(gdb) bt
#0  0xb7822d77 in __strcmp_sse4_2 () from /lib/libc.so.6
#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=0xb60ff178)
     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=0x8a44818, 
typename=typename@entry=0x8319b82 "apic-common")
     at qom/object.c:416
#7  0x0815cf2d in object_dynamic_cast_assert (obj=obj@entry=0x8a44818,
     typename=typename@entry=0x8319b82 "apic-common") at qom/object.c:478
#8  0x08192c1b in cpu_set_apic_tpr (d=0x8a44818, val=8 '\b')
     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=0x8a3ca60, 
run=run@entry=0xb6258000)
     at /home/chris/rpm/BUILD/qemu-kvm-1.1.1/target-i386/kvm.c:1695
#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 0xb7a3ed9e in start_thread () from /lib/libpthread.so.0
#13 0xb77dabbe in clone () from /lib/libc.so.6

Inspecting the args passed into g_str_equal shows:

(gdb) print (gchar *) 0x8a0cd58
$12 = (gchar *) 0x8a0cd58 "apic-common"
(gdb) print (gchar *) 0x8319b82
$13 = (gchar *) 0x8319b82 "apic-common"

So it seems odd that glibc's implementation of strcmp should crash with 
two equal strings. As I say, however, I'm a bit out of my comfort zone 
here, so I may be missing something.

I wouldn't know how to go about disecting type_table, which I assume is 
the hash_table arg passed into g_hash_table_lookup, so advice on how to 
do that and what I am looking for (NULL pointer?) would be helpful.