We have many devices that are all managed under SNMPv3 and we have noticed, while troubleshooting SNMPV3, that if you clear the SNMPV3 cache by sending action 0x10333 to the VNM model at least 3 times consecutively, the SpectroSERVER will crash.
A core file is created, but the data appears to be truncated and unreadable when GDB is run against it.
Spectrum 24.3.x
SNMPV3
This is caused by leaving the dangling pointers in _v3_id_to_ptr_trx_table which is a token-based ID-to-pointer mapping table, which is part of custom memory management system that provides safe, thread-safe access to dynamically allocated objects using unique IDs (tokens) instead of raw pointers.
And in between, if there's an SNMP call cs_get_v3_info_by_id() would fetch/access these dangling pointers and potentially lead to a crash.
This is scheduled to be fixed in Spectrum 25.4.6. In the meantime it is suggested to not clear the SNMPV3 cache multiple times in succession to prevent this crash from happening.