qemu linux-user crash in QOM path canonicalization during do_fork() call to cpu_create

[Serge Belyshev]

qemu-riscv64 version 2.11.50 (v2.11.0-2491-g2bb39a657a) crashes running gcc libgomp.c/sort-1.c testsuite test case with the following message:

(process:11683): GLib-CRITICAL **: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed
**
ERROR:qom/object.c:1665:object_get_canonical_path_component: code should not be reached
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60139c16

Backtrace obtained via gdb:

#0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x0000000060139b21 in abort () at abort.c:79
#2 0x0000000060100505 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x60213ca1 "qom/object.c", line=line@entry=1665,
    func=func@entry=0x60214420 <__func__.18106> "object_get_canonical_path_component", message=message@entry=0x7fffe8000cd0 "code should not be reached")
    at gtestutils.c:2430
#3 0x0000000060100586 in g_assertion_message_expr (domain=0x0, file=0x60213ca1 "qom/object.c", line=1665,
    func=0x60214420 <__func__.18106> "object_get_canonical_path_component", expr=<optimized out>) at gtestutils.c:2453
#4 0x0000000060098334 in object_get_canonical_path_component (obj=0x7fffe81340b0) at qom/object.c:1665
#5 0x0000000060098366 in object_get_canonical_path (obj=0x7fffe81340b0) at qom/object.c:1675
#6 0x000000006008e152 in device_set_realized (obj=0x7fffe81340b0, value=true, errp=0x7ffff762fe68) at hw/core/qdev.c:874
#7 0x0000000060098bf4 in property_set_bool (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", opaque=0x7fffe80fd140, errp=0x7ffff762fe68)
    at qom/object.c:1926
#8 0x0000000060096fee in object_property_set (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1122
#9 0x0000000060099ebd in object_property_set_qobject (obj=0x7fffe81340b0, value=0x7fffe80fd310, name=0x60213694 "realized", errp=0x7ffff762fe68)
    at qom/qom-qobject.c:27
#10 0x0000000060097274 in object_property_set_bool (obj=0x7fffe81340b0, value=true, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1191
#11 0x0000000060092ec5 in cpu_create (typename=0x6250e1a0 "any-riscv-cpu") at qom/cpu.c:61
#12 0x000000006009301a in cpu_generic_init (typename=0x601dd58f "riscv-cpu", cpu_model=0x601dd527 "any") at qom/cpu.c:98
#13 0x000000006004cb61 in cpu_copy (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3881
#14 0x000000006005b79a in do_fork (env=0x7ffff008cd60, flags=4001536, newsp=275531880704, parent_tidptr=275531882704, newtls=275531884288,
    child_tidptr=275531882704) at /opt/qemu/linux-user/syscall.c:6348
#15 0x0000000060063e56 in do_syscall (cpu_env=0x7ffff008cd60, num=220, arg1=4001536, arg2=275531880704, arg3=275531882704, arg4=275531884288,
    arg5=275531882704, arg6=275531884288, arg7=0, arg8=0) at /opt/qemu/linux-user/syscall.c:10001
#16 0x000000006004c89f in cpu_loop (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3600
#17 0x000000006005b68f in clone_func (arg=0x7ffff7775050) at /opt/qemu/linux-user/syscall.c:6311
#18 0x0000000060121797 in start_thread (arg=0x7ffff7632700) at pthread_create.c:463
#19 0x000000006019b4fb in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Attached is a test case source code extracted from libgomp test suite.

Note that it is a multi-threaded and requires 5 or more threads to fail. Number of launched threads is controlled by OMP_NUM_THREADS evironment variable, defaulting to number of hardware threads. Changing constants in the test case makes it fail with different numbers of threads.

I will attach statically linked riscv64 binary executable if size limits permit.

[Serge Belyshev (belyshev)]

I noticed that this crash is not target specific and it is possible to reproduce it using qemu-x86_64 with the testcase above

[jcmvbkbc (jcmvbkbc)]

The following patch should fix that: http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg07437.html

[Peter Maydell (pmaydell)]

Should be fixed by 73a988d957b9142e0 (which is the patch jcmvbkbc mentions in comment #4), now in master and will be in 2.12.0.