Comment 2 for bug 1891203

In further discussions and checks Andrew and I found:

Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/aarch64/strlen.S:94
94 ../sysdeps/aarch64/strlen.S: No such file or directory.

(gdb) bt
#0 strlen () at ../sysdeps/aarch64/strlen.S:94
#1 0x0000aaaaab04fd84 in qmp_query_cpu_model_expansion (type=<optimized out>, model=0xaaaaabcd91b0, errp=errp@entry=0xffffffffee60) at ./target/arm/monitor.c:140
#2 0x0000aaaaab0300a0 in qmp_marshal_query_cpu_model_expansion (args=<optimized out>, ret=0xffffffffef10, errp=0xffffffffef08) at ./b/qemu/qapi/qapi-commands-machine-target.c:183
#3 0x0000aaaaab412ba0 in do_qmp_dispatch (errp=0xffffffffef60, allow_oob=<optimized out>, request=<optimized out>, cmds=0xaaaaabcd92f0) at ./qapi/qmp-dispatch.c:132
#4 qmp_dispatch (cmds=0xaaaaabcd92f0, request=0xffffec006c70, allow_oob=<optimized out>) at ./qapi/qmp-dispatch.c:175
#5 0x0000aaaaab306850 in monitor_qmp_dispatch (mon=0xaaaaabcd91d0, req=<optimized out>) at ./monitor/qmp.c:145
#6 0x0000aaaaab307088 in monitor_qmp_bh_dispatcher (data=<optimized out>) at ./monitor/qmp.c:234
#7 0x0000aaaaab45eb00 in aio_bh_call (bh=0xaaaaabbf32c0) at ./util/async.c:89
#8 aio_bh_poll (ctx=ctx@entry=0xaaaaabbf1e80) at ./util/async.c:117
#9 0x0000aaaaab46243c in aio_dispatch (ctx=0xaaaaabbf1e80) at ./util/aio-posix.c:459
#10 0x0000aaaaab45e9d8 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ./util/async.c:268
#11 0x0000fffff7d1bc30 in g_main_context_dispatch () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#12 0x0000aaaaab46147c in glib_pollfds_poll () at ./util/main-loop.c:219
#13 os_host_main_loop_wait (timeout=187650001905680) at ./util/main-loop.c:242
#14 main_loop_wait (nonblocking=<optimized out>) at ./util/main-loop.c:518
#15 0x0000aaaaab113330 in main_loop () at ./vl.c:1810
#16 0x0000aaaaaaed4bd0 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ./vl.c:4492
(gdb)

Which is a reaction to the probing of caps like:
$ nc 127.0.0.1 4444
{"QMP": {"version": {"qemu": {"micro": 0, "minor": 2, "major": 4}, "package": "Debian 1:4.2-3ubuntu6.3~cloud0"}, "capabilities": ["oob"]}}
{ "execute": "qmp_capabilities" }
{"return": {}}
{"execute":"query-cpu-model-expansion","arguments":{"type":"full","model":{"name":"host"}}}

So it is passing a null pointer and breaking.

Not 100% that this "is it", but worth taking a look for sure

@Andrew - with debug symbols and backtrace it already makes more sense :-)

(gdb) frame 1
#1 0x0000aaaaab04fd84 in qmp_query_cpu_model_expansion (type=<optimized out>, model=0xaaaaabcd91b0, errp=errp@entry=0xffffffffee60) at ./target/arm/monitor.c:140
140 int len = strlen(cpu_type) - strlen(ARM_CPU_TYPE_SUFFIX);
(gdb) p cpu_type
$1 = 0x0

This is from current_machine->cpu_type

(gdb) p *current_machine
$3 = {parent_obj = {class = 0xaaaaabc1aa30, free = 0xfffff7d21680 <g_free>, properties = 0xaaaaabcc0cc0, ref = 2, parent = 0xaaaaabcc33d0}, sysbus_notifier = {
    notify = 0xaaaaab18f320 <machine_init_notify>, node = {le_next = 0xaaaaabadaf20 <chardev_machine_done_notify>, le_prev = 0xaaaaabb17558 <machine_init_done_notifiers>}},
  accel = 0xaaaaabcce080 "kvm", kernel_irqchip_allowed = true, kernel_irqchip_required = false, kernel_irqchip_split = false, kvm_shadow_mem = -1, dtb = 0x0, dumpdtb = 0x0,
  phandle_start = 0, dt_compatible = 0x0, dump_guest_core = true, mem_merge = true, usb = false, usb_disabled = false, igd_gfx_passthru = false, firmware = 0x0, iommu = false,
  suppress_vmdesc = false, enforce_config_section = false, enable_graphics = false, memory_encryption = 0x0, device_memory = 0x0, ram_size = 0, maxram_size = 0, ram_slots = 0,
  boot_order = 0x0, kernel_filename = 0x0, kernel_cmdline = 0xaaaaab700a78 "", initrd_filename = 0x0, cpu_type = 0x0, accelerator = 0xaaaaabccf820, possible_cpus = 0x0, smp = {cpus = 1,
    cores = 1, threads = 1, max_cpus = 1}, nvdimms_state = 0x0, numa_state = 0x0}

So yes this is zero, but why is the question

Also we need to compare this with Focal-ussuri which was mentioned to be working