[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Abort with qemu-aarch64(latest git master)
From: |
Alex Bennée |
Subject: |
Re: [Qemu-devel] Abort with qemu-aarch64(latest git master) |
Date: |
Wed, 10 Aug 2016 16:34:32 +0100 |
User-agent: |
mu4e 0.9.17; emacs 25.1.4 |
Pranith Kumar <address@hidden> writes:
> I am seeing an abort when I run qemu-aarch64 on a multi-threaded ARM64
> executable. Is this a valid use case or is multi-threading still not
> supported?
>
> The back trace is as follows. You can find it as a paste for easier reading
> here: http://paste.ubuntu.com/22734688/
>
> #0 0x00007ffff684c418 in __GI_raise (address@hidden) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1 0x00007ffff684e01a in __GI_abort () at abort.c:89
> #2 0x00007ffff688e72a in __libc_message (address@hidden,
> address@hidden "*** Error in `%s': %s: 0x%s ***\n") at
> ../sysdeps/posix/libc_fatal.c:175
> #3 0x00007ffff689648d in malloc_printerr (ar_ptr=0x7ffff6bdab20
> <main_arena>, ptr=<optimized out>, str=0x7ffff69a7728 "free(): invalid next
> size (fast)", action=3) at malloc.c:5007
> #4 _int_free (have_lock=1, p=<optimized out>, av=0x7ffff6bdab20
> <main_arena>) at malloc.c:3868
> #5 free_check (mem=<optimized out>, caller=<optimized out>) at hooks.c:324
> #6 0x00007ffff689ab67 in __GI___libc_free (mem=<optimized out>) at
> malloc.c:2943
> #7 0x00007ffff7afdf2d in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #8 0x00007ffff7afe0cf in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #9 0x00007ffff7afe4ba in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #10 0x00005555556a7490 in object_property_add (obj=0x555557a17600,
> name=0x555557b530f0 "device[7]", type=0x555557b53170 "child<any-arm-cpu>",
> get=0x5555556a82e1 <object_get_child_property>, set=0x0,
> release=0x5555556a8375 <object_finalize_child_property>,
> opaque=0x555557b3eb00, errp=0x7ffff7f42eb0) at
> /home/pranith/devops/code/qemu/qom/object.c:947
> #11 0x00005555556a8490 in object_property_add_child (obj=0x555557a17600,
> name=0x555557b530f0 "device[7]", child=0x555557b3eb00, errp=0x5555579f6478
> <error_abort>)
> at /home/pranith/devops/code/qemu/qom/object.c:1382
> #12 0x000055555569f7b7 in device_set_realized (obj=0x555557b3eb00,
> value=true, errp=0x7ffff7f430b0) at
> /home/pranith/devops/code/qemu/hw/core/qdev.c:902
> #13 0x00005555556a94d1 in property_set_bool (obj=0x555557b3eb00,
> v=0x555557b52fb0, name=0x55555572388f "realized", opaque=0x555557b50ee0,
> errp=0x7ffff7f430b0) at /home/pranith/devops/code/qemu/qom/object.c:1853
> #14 0x00005555556a79dc in object_property_set (obj=0x555557b3eb00,
> v=0x555557b52fb0, name=0x55555572388f "realized", errp=0x7ffff7f430b0) at
> /home/pranith/devops/code/qemu/qom/object.c:1087
> #15 0x00005555556aa804 in object_property_set_qobject (obj=0x555557b3eb00,
> value=0x555557b52eb0, name=0x55555572388f "realized", errp=0x7ffff7f430b0) at
> /home/pranith/devops/code/qemu/qom/qom-qobject.c:27
> #16 0x00005555556a7c7f in object_property_set_bool (obj=0x555557b3eb00,
> value=true, name=0x55555572388f "realized", errp=0x7ffff7f430b0) at
> /home/pranith/devops/code/qemu/qom/object.c:1156
> #17 0x00005555556a416c in cpu_generic_init (typename=0x55555570bef9
> "arm-cpu", cpu_model=0x55555570457d "any") at
> /home/pranith/devops/code/qemu/qom/cpu.c:76
> #18 0x000055555563c729 in cpu_arm_init (cpu_model=0x55555570457d "any") at
> /home/pranith/devops/code/qemu/target-arm/helper.c:5101
> #19 0x00005555555d030f in cpu_copy (env=0x555557abc6a0) at
> /home/pranith/devops/code/qemu/linux-user/main.c:3808
> #20 0x00005555555de45c in do_fork (env=0x555557abc6a0, flags=4001536,
> newsp=274939877808, parent_tidptr=274939879792, newtls=274939881360,
> child_tidptr=274939879792)
> at /home/pranith/devops/code/qemu/linux-user/syscall.c:5829
So this is do_fork which in linux-user spins up a new thread associated
with a new "vCPU". None of this is path is protected although the crash
occurs in malloc which should already be thread safe but I guess a crash
could be triggered if an address got corrupted.
I wonder if the async safe work mechanism could be used to create this
vCPU in a quiescent state or if that would be overkill?
> #21 0x00005555555e5e89 in do_syscall (cpu_env=0x555557abc6a0, num=220,
> arg1=4001536, arg2=274939877808, arg3=274939879792, arg4=274939881360,
> arg5=274939879792, arg6=274939881360, arg7=0, arg8=0)
> at /home/pranith/devops/code/qemu/linux-user/syscall.c:9211
> #22 0x00005555555d001d in cpu_loop (env=0x555557abc6a0) at
> /home/pranith/devops/code/qemu/linux-user/main.c:1079
> #23 0x00005555555de387 in clone_func (arg=0x7fffffffbcd0) at
> /home/pranith/devops/code/qemu/linux-user/syscall.c:5798
> #24 0x00007ffff6be76fa in start_thread (arg=0x7ffff7f45700) at
> pthread_create.c:333
> #25 0x00007ffff691db5d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
--
Alex Bennée