[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.