Understanding a gdb backtrace

I get a gdb backtrace shown below consistently. Would this indicate a failure in doing malloc( ) ? If so, I also let a "free -m" run on the Linux box and I can't seem to find a discrepancy. xsd__anyType is a typedef of soap_dom_element

(gdb) bt
#0  0x0000007f9af24090 in raise () from /tmp/../lib/libc.so.6
#1  0x0000007f9af12894 in abort () from /tmp/../lib/libc.so.6
#2  0x0000007f9af5c950 in ?? () from /tmp/../lib/libc.so.6
#3  0x0000007f9af62d64 in ?? () from /tmp/../lib/libc.so.6
#4  0x0000007f9af66158 in ?? () from /tmp/../lib/libc.so.6
#5  0x0000007f9af67550 in malloc () from /tmp/../lib/libc.so.6
#6  0x0000007f9b8b909c in soap_malloc () from /opt/ad/lib/libjci_gsoap.so
#7  0x0000007f9b8d4d40 in ?? () from /opt/ad/lib/libjci_gsoap.so
#8  0x0000007f9b8d5834 in soap_in_xsd__anyType(soap*, char const*, soap_dom_element*, char const*) () from /opt/ad/lib/libjci_gsoap.so
#9  0x0000007f9b8d5874 in soap_in_xsd__anyType(soap*, char const*, soap_dom_element*, char const*) () from /opt/ad/lib/libjci_gsoap.so
#10 0x0000007f9b8d5874 in soap_in_xsd__anyType(soap*, char const*, soap_dom_element*, char const*) () from /opt/ad/lib/libjci_gsoap.so
#11 0x0000007f9b8d5874 in soap_in_xsd__anyType(soap*, char const*, soap_dom_element*, char const*) () from /opt/ad/lib/libjci_gsoap.so
#12 0x0000007f9b8d6fe4 in operator>>(std::istream&, soap_dom_element&) () from /opt/ad/lib/libjci_gsoap.so
#13 0x0000000000507274 in tev::Events::getSubscriptionReference[abi:cxx11](char const*) const (this=this@entry=0x7f99eb25b0,
    msgBuf=0x7f99ec0218 "POST /onvif/event_service HTTP/1.0\r\nContent-Type: application/soap+xml; charset=utf-8\r\nHost: 192.168.184.35\r\nContent-Length: 1438\r\nAccept-Encoding: gzip, deflate\r\nX-Forwarded-For: ::ffff:192.168.185.1"...) at /home/jbloomrp/sandboxes/acvs-illustra-global/toolchain/arm/linaro-aarch64-2018.08-gcc8.2/work/amb_cv22_evk/arm/release/linaro-aarch64-2018.08-gcc8.2/aarch64-linux-gnu/include/c++/8.2.1/bits/unique_ptr.h:342

If malloc is a failure, then I should see it spiral towards 0 which doesn't seem to be the case.

Swap:             0           0           0
              total        used        free      shared  buff/cache   available
Mem:           1983         995         703         147         285         826


Swap:             0           0           0
              total        used        free      shared  buff/cache   available
Mem:           1983        1038         659         147         285         782
Swap:             0           0           0

Even at the lowest I could see free mem was still 659.