summary refs log tree commit diff stats
path: root/gitlab/issues/target_missing/host_missing/accel_missing/2265.toml
blob: 6d104fc4af869223c8cc22d1a0ceb1832cde2f7e (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
id = 2265
title = "qemu-system-x86_64 crash creating snapshot"
state = "opened"
created_at = "2024-04-03T08:00:37.783Z"
closed_at = "n/a"
labels = []
url = "https://gitlab.com/qemu-project/qemu/-/issues/2265"
host-os = "debian 10 buster"
host-arch = "x86"
qemu-version = "6.2.0"
guest-os = "debian 10 buster"
guest-arch = "x86"
description = """I'm facing a crash in qemu-system-x86_64.\\
I crash because bs->children.lh_first is null and QLIST_NEXT try dereference the pointer. It triggers a SIGSEGV\\
The manner to reproduce is too complex to give on gitlab and the version is not recent. (I reproduce also with 7.1)\\

here is the stack:

(gdb) p bs->children\\
$1 = {lh_first = 0x0}\\
(gdb)\\
(gdb) p child\\
$2 = (BdrvChild *) 0x0\\
(gdb)\\
    if (bs->implicit) {\\
        /* For implicit nodes, just copy everything from the single child */\\
        child = QLIST_FIRST(&bs->children);\\
----->> assert(QLIST_NEXT(child, next) == NULL);\\
        pstrcpy(bs->exact_filename, sizeof(bs->exact_filename),\\


#0  bdrv_refresh_filename (bs=0x562927927000) at ../qemu-6.2.0/block.c:7525\\
#1  0x000056292527dd97 in bdrv_block_device_info (blk=blk@entry=0x0, bs=bs@entry=0x562927927000, flat=flat@entry=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block/qapi.c:58\\
#2  0x00005629252470c0 in bdrv_named_nodes_list (flat=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block.c:5863\\
#3  0x000056292523da7e in qmp_query_named_block_nodes (has_flat=<optimized out>, flat=<optimized out>, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/blockdev.c:2935\\
#4  0x0000562925301ebd in qmp_marshal_query_named_block_nodes (args=<optimized out>, ret=0x7fc833c83e88, errp=0x7fc833c83e80) at qapi/qapi-commands-block-core.c:423\\
#5  0x0000562925344129 in do_qmp_dispatch_bh (opaque=0x7fc833c83e90) at ../qemu-6.2.0/qapi/qmp-dispatch.c:129
#6  0x000056292535ecf5 in aio_bh_call (bh=0x5629295ab560) at ../qemu-6.2.0/util/async.c:141\\
#7  aio_bh_poll (ctx=ctx@entry=0x5629276c93e0) at ../qemu-6.2.0/util/async.c:169\\
#8  0x000056292534cf9e in aio_dispatch (ctx=0x5629276c93e0) at ../qemu-6.2.0/util/aio-posix.c:381\\
#9  0x000056292535eb9e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311\\
#10 0x00007fc8351cafee in g_match_info_fetch_pos () from /lib/x86_64-linux-gnu/libglib-2.0.so.0\\
#11 0x00007fc800000000 in ?? ()\\
#12 0x000003a05cb8b408 in ?? ()\\
#13 0x0000000000000000 in ?? ()\\

The case lh_first = 0x0 seems to be common, but never when bs->implicit is true. bs->implicit seems to be switch to true by another thread.\\
Because the qemu version and the system are too old, I'm not expecting a patch, I'm just requesting an opinion.\\

I fixed the problem by just doing:\\
child = QLIST_FIRST(&bs->children);\\
if (bs->implicit && (child != NULL)) {\\
   assert(QLIST_NEXT(child, next) == NULL);\\
   ....\\
}\\
I don't have the qemu knowledge to evaluate it and consequences.\\
Is there anyone who have any idea ?\\
Thank you very much.\\"""
reproduce = "n/a"
additional = "n/a"