O/S Ubuntu 22.04
Changes in the ProcessOne XMPP Erlang package between releases 1.5.4 and 1.5.6 cause crashes in OpenSRF when the latter handles a XMPP error message. This is most easily seen when making a request to an OpenSRF service that does not exist. srfsh will segfault as the transport client code attempts to access a non-existent "code" attribute on the error element. The code extension attribute was removed from the XMPP Erlang library in August of 2021. The code attribute was deprecated prior to the release of RFC 3920 in 2004. Ejabbered and the ProessOne XMPP library both continued to support it for legacy clients for a number of years.
The standard way to deal with XMPP errors is to use the error condition element which should be the first child of the error element.
My recommendation is that we add an "error_condition" character pointer to the transport_message_struct and use this instead of the "error_code" field. If we must continue to use the error_code, XEP-0086 provides suggested mappings between the error condition string and numbers: https://xmpp.org/extensions/xep-0086.html. Constants for these values are already provided in the osrf_message.h header file.
This issue was uncovered while implementing bug 1970667.
I've taken an initial lo look at this. There seems to be very little code that's doing more with the <error> element's code and type attributes besides logging them, so it's looking easier than I expected to drop any expectation that XEP-0086 is supported. In fact, we might be able to pull off a fix without even breaking ABI for Evergreen.