From: "Alex Bennée" <alex.bennee@linaro.org>
To: Pranith Kumar <bobby.prani@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Abort with qemu-aarch64(latest git master)
Date: Wed, 10 Aug 2016 16:34:32 +0100 [thread overview]
Message-ID: <8737mcd4dz.fsf@linaro.org> (raw)
In-Reply-To: <8760rbt21w.fsf@gmail.com>
Pranith Kumar <bobby.prani@gmail.com> 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 (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1 0x00007ffff684e01a in __GI_abort () at abort.c:89
> #2 0x00007ffff688e72a in __libc_message (do_abort=do_abort@entry=2,
> fmt=fmt@entry=0x7ffff69a76b0 "*** 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
prev parent reply other threads:[~2016-08-10 15:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-08 20:53 [Qemu-devel] Abort with qemu-aarch64(latest git master) Pranith Kumar
2016-08-09 8:00 ` Peter Maydell
2016-08-09 16:15 ` Alex Bennée
2016-08-09 16:37 ` Pranith Kumar
2016-08-10 15:34 ` Alex Bennée [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8737mcd4dz.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=bobby.prani@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.