Re: [PATCH] tools/ocaml: fill arch_config for ARM in domain_getinfolist

Julian Vetter <[email protected]>
Newsgroups org.xenproject.lists.xen-devel
Message-ID <1785245280.8631fc262581453bbf619ec5b2062170.19fa8e926d1000e099@vates.tech>
On 7/28/26 14:59, Andrew Cooper wrote:
> On 27/07/2026 10:11 am, Julian Vetter wrote:
>> In the function alloc_domaininfo() the arch_config field in domaininfo
>> is only filled inside #if defined(__i386__) || defined(__x86_64__). On
>> ARM the field is left unpopulated. caml_alloc_tuple() does not zero new
>> blocks,
> 
> Hmm.  Yes it does.  caml_alloc_tuple() calls caml_alloc() which
> initialises with Val_unit everywhere.
> 
> It is only caml_alloc_small() which doesn't allocate, and potentially
> ends up with garbage.
> 
> Do you have details of the crash?  I think it ought to be a plain
> NULL(ish) deference from trying to interpret Val_unit as a pointer.
> 

Sorry, you're right. My phrasing is actually wrong. Because as you said, 
it's not garbage. Because it is zero'ed. It's just a "almost" NULL 
pointer dereference and it terminates with a SIGSEGV.

I created a backtrace yesterday. Unfortunately I replaced the binaries 
already and modified a lot of stuff in between for debugging. But here 
are the details from my notes:

$ coredumpctl debug -1
...
Core was generated by `/usr/sbin/xenopsd-xc --config /etc/xenopsd.conf 
--config-dir /etc/xenopsd.conf.'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000aaaadd311728 in camlXenops_server_xen__fun_14373 ()
[Current thread is 1 (LWP 21348)]

(gdb) bt
#0  camlXenops_server_xen__fun_14373 ()
      at ocaml/xenopsd/xc/xenops_server_xen.ml:3368
#1  0x0000aaaadd390d34 in camlXenops_server__fun_17304 ()
     at ocaml/xenopsd/lib/xenops_server.ml:3229
#2  0x0000aaaadd372c64 in camlXenops_task__with_tracing_1305 ()
     at ocaml/xenopsd/lib/xenops_task.ml:103
#3  0x0000aaaadd394100 in camlXenops_server__one_7593 ()
     at ocaml/xenopsd/lib/xenops_server.ml:3401
#4  0x0000aaaadd3943e8 in camlXenops_server__fun_19063 ()
     at ocaml/xenopsd/lib/xenops_server.ml:3432
#5  0x0000aaaadd3be558 in camlTask_server__run_1022 ()
     at ocaml/xapi-idl/lib/task_server.ml:192
#6  0x0000aaaadd45ab2c in camlDebug__fun_2365 () at 
ocaml/libs/log/debug.ml:258
#7  0x0000aaaadd556dec in camlBacktrace__with_backtraces_1095 ()
#8  0x0000aaaadd45aa0c in camlDebug__with_thread_associated_inner_2357 ()
     at ocaml/libs/log/debug.ml:257
#9  0x0000aaaadd38359c in camlXenops_server__fun_13600 ()
     at ocaml/xenopsd/lib/xenops_server.ml:1174
#10 0x0000aaaadd5b4b84 in camlThread__fun_850 ()
#11 0x0000aaaadd6700c8 in caml_start_program ()
#12 0x0000aaaadd664a2c in caml_callback_exn ()
#13 0x0000aaaadd63ee88 in caml_thread_start ()
#14 0x0000ffffb0ecba88 in start_thread () from /lib64/libc.so.6
#15 0x0000ffffb0f36e8c in thread_start () from /lib64/libc.so.6


Line 3368 is match di.Xenctrl.arch_config with ARM _ -> true | X86 _ -> 
false

ldr x0, [sp, #192]      ; x0 = di # -> the domaininfo tuple pointer
ldr x23, [x0, #128]     ; x23 = Field(di, 16) # -> word 16 = arch_config

and then it faults on the very next instruction when it tries to 
determine whether it's ARM or x86.

> ~Andrew
> 



-- 
Julian Vetter | Vates Hypervisor & Kernel Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.