This work is based on a patch sent by Amar Padmanabhan.

I'm not sure this is the right thing to do.

Here is the report from Amar Padmanabhan, describing the problem:
-------------------------------------------------------------------------
There is a memcopy in the s1ap_decoder after the call to aper_decode

READ of size 8 at 0x60200001ea70 thread T6
    #0 0x6694c4 in s1ap_decode_s1ap_s1setuprequesties ../buildDebug/s1ap/R10.5/s1ap_decoder.c:6673
    #1 0x552505 in s1ap_mme_decode_initiating /home/vagrant/magma/c/oai/s1ap/s1ap_mme_decoder.c:64
    #2 0x553b3c in s1ap_mme_decode_pdu /home/vagrant/magma/c/oai/s1ap/s1ap_mme_decoder.c:217
    #3 0x54b300 in s1ap_mme_thread /home/vagrant/magma/c/oai/s1ap/s1ap_mme.c:116
    #4 0x7f81d46380a3 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x80a3)
    #5 0x7f81d27dd62c in clone (/lib/x86_64-linux-gnu/libc.so.6+0xe862c)

Here is the trace of the call to aper_decode which actually frees the underlying memory

    #0 0x7f81d48a1527 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x54527)
    #1 0x546e24 in NativeEnumerated_decode_aper ../buildDebug/s1ap/R10.5/NativeEnumerated.c:186
    #2 0x6c7622 in S1ap_PagingDRX_decode_aper ../buildDebug/s1ap/R10.5/S1ap-PagingDRX.c:125
    #3 0x52c93f in aper_decode ../buildDebug/s1ap/R10.5/per_decoder.c:163
    #4 0x4facb4 in ANY_to_type_aper ../buildDebug/s1ap/R10.5/ANY.c:216
    #5 0x6692f8 in s1ap_decode_s1ap_s1setuprequesties ../buildDebug/s1ap/R10.5/s1ap_decoder.c:6663
-------------------------------------------------------------------------