The stack backtrace is as follows:
(gdb) bt
#0 0x00007f1dc3c7b091 in _g_log_abort () from /usr/lib64/libglib-2.0.so.0
#1 0x00007f1dc3c7c0bd in g_log_default_handler () from
/usr/lib64/libglib-2.0.so.0
#2 0x00007f1dc3c7c341 in g_logv () from /usr/lib64/libglib-2.0.so.0
#3 0x00007f1dc3c7c5cf in g_log () from /usr/lib64/libglib-2.0.so.0
#4 0x00007f1dc3c7ac4c in g_malloc () from /usr/lib64/libglib-2.0.so.0
#5 0x00000000008300b7 in qstring_from_substr (
str=0x7f13a2e67010 "00000000777b8000: 0000000003083000
----A--U-\r\n00000000777b9000: 0000000005984000 ----A--U-\r\n00000000777ba000:
0000000005985000 ----A--U-\r\n00000000777bb000: 0000000003086000
----A--U-\r\n00000000777bc000"..., start=start@entry=0, end=<optimized out>) at
qobject/qstring.c:51
#6 0x0000000000830113 in qstring_from_str (str=<optimized out>) at
qobject/qstring.c:66
#7 0x000000000082be98 in qobject_output_type_str (v=<optimized out>,
name=0x89703b "unused", obj=0x7ffff0135f98, errp=<optimized out>)
at qapi/qobject_output_visitor.c:172
#8 0x0000000000829d2c in visit_type_str (v=v@entry=0x4d9d940,
name=name@entry=0x89703b "unused", obj=obj@entry=0x7ffff0135f98,
errp=errp@entry=0x7ffff0135fa8)
at qapi/qapi_visit_core.c:291
#9 0x0000000000576135 in qmp_marshal_output_str (
ret_in=0x7f13a2e67010 "00000000777b8000: 0000000003083000
----A--U-\r\n00000000777b9000: 0000000005984000 ----A--U-\r\n00000000777ba000:
0000000005985000 ----A--U-\r\n00000000777bb000: 0000000003086000
----A--U-\r\n00000000777bc000"..., ret_out=ret_out@entry=0x7ffff0136068,
errp=errp@entry=0x7ffff0135fe8) at qmp-marshal.c:2022
#10 0x00000000005762cb in qmp_marshal_human_monitor_command (args=<optimized
out>, ret=0x7ffff0136068, errp=0x7ffff0136060) at qmp-marshal.c:2059
#11 0x000000000082c897 in do_qmp_dispatch (request=request@entry=0x1fcda50,
errp=errp@entry=0x7ffff01360b8) at qapi/qmp_dispatch.c:114
#12 0x000000000082caeb in qmp_dispatch (request=request@entry=0x1fcda50) at
qapi/qmp_dispatch.c:141
#13 0x000000000045e0d2 in handle_qmp_command (parser=<optimized out>,
tokens=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:3907
#14 0x000000000083355e in json_message_process_token (lexer=0x1a608e8,
input=0x19f26e0, type=JSON_RCURLY, x=94, y=263) at qobject/json_streamer.c:105
#15 0x0000000000861650 in json_lexer_feed_char (lexer=lexer@entry=0x1a608e8,
ch=125 '}', flush=flush@entry=false) at qobject/json_lexer.c:319
#16 0x0000000000861766 in json_lexer_feed (lexer=0x1a608e8, buffer=<optimized
out>, size=<optimized out>) at qobject/json_lexer.c:369
#17 0x0000000000833661 in json_message_parser_feed (parser=<optimized out>,
buffer=<optimized out>, size=<optimized out>) at qobject/json_streamer.c:124
#18 0x000000000045cc32 in monitor_qmp_read (opaque=<optimized out>,
buf=<optimized out>, size=<optimized out>) at
/usr/src/debug/qemu-kvm-2.8.1/monitor.c:3937
#19 0x00000000005652f3 in tcp_chr_read (chan=<optimized out>, cond=<optimized
out>, opaque=0x1a5c020) at qemu_char.c:3253
#20 0x00007f1dc3c75609 in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#21 0x0000000000779a06 in glib_pollfds_poll () at main_loop.c:228
#22 0x0000000000779aab in os_host_main_loop_wait (timeout=4830848) at
main_loop.c:273
#23 0x0000000000779bd5 in main_loop_wait (nonblocking=nonblocking@entry=0) at
main_loop.c:521
#24 0x0000000000570851 in main_loop () at vl.c:2100
#25 0x0000000000420d1e in main (argc=<optimized out>, argv=<optimized out>,
envp=<optimized out>) at vl.c:4980
> -----Original Message-----
> From: Markus Armbruster [mailto:arm...@redhat.com]
> Sent: Monday, July 23, 2018 11:46 PM
> To: liujunjie (A) <liujunji...@huawei.com>
> Cc: wangxin (U) <wangxinxin.w...@huawei.com>; Gonglei (Arei)
> <arei.gong...@huawei.com>; Huangweidong (C)
> <weidong.hu...@huawei.com>; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH] qstring: Fix integer overflow
>
> "liujunjie (A)" <liujunji...@huawei.com> writes:
>
> > Thanks for your reply.
> >> Really? How exactly can this happen? Please explain step by step.
> > There exist a qemu core related to this. You have mention that "The
> conversion truncates when strlen(str) - 1 exceeds INT_MAX".
> > Later in function qstring_from_substr, this truncated "end" will be assigned
> to "qstring->length" again, which is size_t. This is the key point why qemu
> coredumped.
> > Because when "end" is truncated, it can be negative number. If we assign a
> negative number to a size_t variable, this size_t variable can become very
> large.
> > At last, we call g_malloc to try to alloc a large number of member which
> cannot success. So qemu coredump.
> > In my example, use gdb to debug function qstring_from_substr, I can get the
> following message.
> > (gdb) p qstring->length
> > $4 = 18446744072383980732 (too large to allocate)
> > (gdb) p (int) (qstring->length)
> > $5 = -1325570884
> > (gdb) p/x (int) qstring->length
> > $6 = 0xb0fd64bc
> > (gdb) p/x qstring->length
> > $7 = 0xffffffffb0fd64bc
> > (gdb) p end
> > $8 = <optimized out>
>
> Can you provide a stack backtrace, too?
