This article explains about the proxy-xml core dumps seen when customer have deployed custom yang sensor path using proxy-xml.
Check for the core-dumps and backtrace as below also check the amount of sensors configured in the device using the below cli command:
labroot@Router_A> show system core-dumps
/var/crash\/*core*: No such file or directory
-rw-rw---- 1 root wheel 63096053 Mar 31 20:36 /var/tmp/xmlproxyd.core-tarball.0.tgz
-rw-rw---- 1 root wheel 67312343 Apr 1 08:39 /var/tmp/xmlproxyd.core-tarball.1.tgz
-rw-rw---- 1 root wheel 73737067 Apr 2 04:20 /var/tmp/xmlproxyd.core-tarball.2.tgz
/var/tmp/pics\/*core*: No such file or directory
/var/crash/kernel.*: No such file or directory
/var/jails/rest-api/tmp\/*core*: No such file or directory
/tftpboot/corefiles\/*core*: No such file or directory
total files: 3
(gdb) bt
#0 memset () at /volume/build/junos/occam/llvm-13.0/sandbox-bsd15-244-20250701-5b0ec39/freebsd/bsd15_244/20250701.220450_builder_bsd15_244.5b0ec39/src/lib/libc/i386/string/memset.S:76
#1 0x00000000 in ?? ()
(gdb) bt full
No locals.
No symbol table info available.
(gdb)
{master}
labroot@Router_A> show agent sensors | match xmlproxy | count
Jun 30 15:02:47
Count: 81 lines
From the core files and it seems like there are huge number of proxy-xml sensors created and subscribed. The core files indicate 81 and 65 sensors in total.
This is beyond the normal usage of xmlproxyd sensors and looks to be unsupported scale at the first glance.
The process is running out of memory because of high memory allocation for all these sensors and hence crashing.
Basically the sensors count is very high and to add more information about the same please find the below details:
xmlproxyd was not designed as a full-fledged solution to stream telemetry data for any component that isn't telemetry capable yet. It was/is just a stop gap solution for small CLI commands and a handful of sensors.
The most optimal way is for the owners/producers to natively implement these sensors (the operational states in CLI cmds) and then stream it out. xmlproxyd was proposed as the temporary solution till they make that data natively available via telemetry.
That being said, xmlproxyd will run out of memory and won't be able to perform optimally if the number of sensors are so high.
There is a public documentation for the same:
Configure a NETCONF Proxy Telemetry Sensor in Junos | Junos OS | Juniper Networks