Asterisk Crash coredump report json_mem_free

I have on a server with a script written in python 3.6, it monitors some channels via ARI connected by websocket, the asterisk is crashing randomly.
Coredump shows the following message

#0  0x00007f479f53e207 in raise () at /usr/lib64/
#1  0x00007f479f53f8f8 in abort () at /usr/lib64/
#2  0x00007f479f580d27 in __libc_message () at /usr/lib64/
#3  0x00007f479f589489 in _int_free () at /usr/lib64/
#4  0x0000000000532cc1 in json_mem_free (mem=0x7f47501f93f0) at json.c:84
        __PRETTY_FUNCTION__ = "json_mem_free"
#5  0x0000000000532ff7 in ast_json_unref (json=0x7f47148657b8) at json.c:254
        free_list = 0x7f4714009cf0
        mem = 0x7f47501f93f0
#6  0x00007f472cf476ad in sub_default_handler (data=0x7f4710002688, sub=0x7f47100023d8, message=0x7f475001ad00) at stasis/app.c:373
        app = 0x7f4710002688
        json = 0x7f47148657b8
#7  0x00000000005d9c8d in router_dispatch (data=0x7f4710002348, sub=0x7f47100023d8, message=0x7f475001ad00) at stasis_message_router.c:201
        router = 0x7f4710002348
        route = {message_type = 0x0, callback = 0x7f472cf47621 <sub_default_handler>, data = 0x7f4710002688}
#8  0x00000000005c8564 in subscription_invoke (sub=0x7f47100023d8, message=0x7f475001ad00) at stasis.c:587
        final = 0
        message_type_id = 4
        __PRETTY_FUNCTION__ = "subscription_invoke"
#9  0x00000000005c960a in dispatch_exec_async (local=0x7f46df906c60) at stasis.c:1045
        sub = 0x7f47100023d8
        message = 0x7f475001ad00
#10 0x00000000005e63ac in ast_taskprocessor_execute (tps=0x7f4710002518) at taskprocessor.c:990
        local = {local_data = 0x7f47100023d8, data = 0x7f475001ad00}
        t = 0x7f475001ae00
        size = 19
        __PRETTY_FUNCTION__ = "ast_taskprocessor_execute"
#11 0x00000000005e4657 in default_tps_processing_function (data=0x7f47100024b8) at taskprocessor.c:191
        listener = 0x7f47100024b8
        tps = 0x7f4710002518
        pvt = 0x7f4710001cc0
        sem_value = -544182896
        res = 0
        __PRETTY_FUNCTION__ = "default_tps_processing_function"
#12 0x00000000005fb580 in dummy_start (data=0x7f4710002630) at utils.c:1239
        __cancel_buf = 
            {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, -8976124672249168105, 0, 512000, 0, 139942375225088, -8976124672291111145, 9071333444719607575}, __mask_was_saved = 0}}, __pad = {0x7f46df906db0, 0x0, 0x0, 0x0}}
        __cancel_routine = 0x45359c <ast_unregister_thread>
        __cancel_arg = 0x7f46df907700
        __not_first_call = 0
        ret = 0x0
---Type <return> to continue, or q <return> to quit---
        a = 
          {start_routine = 0x5e45c1 <default_tps_processing_function>, data = 0x7f47100024b8, name = 0x7f4710002c70 "default_tps_processing_function started at [  208] taskprocessor.c default_listener_start()"}
#13 0x00007f47a0263dd5 in start_thread () at /usr/lib64/
#14 0x00007f479f605ead in clone () at /usr/lib64/

the debug log shows no errors.

I have other servers with the same script running but they do not hang, the difference is that the simultaneous calls are on average 20 per minute on the servers that are dropping.

The python script is connected via proxy by apache, not directly connected to the ARI websocket.

The python script does not report any programming errors.

My doubts are:

  • Can the Asterisk websocket break for some overhead?

  • Has anyone ever had a similar problem?

This is from the jansson library itself. What version of Asterisk is in use? What version of libjansson?

Asterisk version is 13.25.0 ->

Did you just edit that comment? Didn’t it say jansson-2.7 a moment ago?

Yes a say but i have check in my /usr/src, they have a folder named jansson-2.7, but when i run: ldconfig -v | grep libjansson, the return is: ->