Asterisk 13.20 - Frack on stasis_app_subscribe

Hello,
Since I implemented adding/removing subscriptions using ARI, I started having crashes on the Asterisk server.
Before the crash I get “INTERNAL_OBJ: FRACK!”.
In my server application I usually remove subscription and then add it again everytime my application is started.

SCENARIO
That frack and subsequently the crash only happen when I have multiple server applications connecting to the asterisk server. On production where I only have 1 server application and 2 asterisk servers running, i don’t see this happening. But on development environment it happens a lot.
I tried to upgrade my asterisk version from 13.18 to 13.20 as there were many fixes related to subscriptions on the changelog file, but that didn’t solve the problem.
I was able to reproduce it by starting two server applications at the same time (Log below). Sometimes it gives me a frack on stasis_app_subscribe and sometimes on stasis_app_unsubscribe.

ARI ADD/REMOVE SUBSCRIPTION
DELETE /ari/applications/agent-request-fabio/subscription?eventSource=endpoint:PJSIP
POST /ari/applications/agent-request-fabio/subscription?eventSource=endpoint:PJSIP

ERROR FROM THE LOG:
[Apr 17 15:00:54] ERROR[2655]: astobj2.c:131 INTERNAL_OBJ: FRACK!, Failed assertion bad magic number 0x0 for object 0x7f05b80015f8 (0)
Got 18 backtrace records
#0: [0x45c241] /usr/sbin/asterisk(__ao2_cleanup+0x111) [0x45c241]
#1: [0x7f05b37bf790] /usr/lib64/asterisk/modules/res_stasis.so(+0x10790) [0x7f05b37bf790]
#2: [0x7f05b37be876] /usr/lib64/asterisk/modules/res_stasis.so(+0xf876) [0x7f05b37be876]
#3: [0x7f05b37b6330] /usr/lib64/asterisk/modules/res_stasis.so(+0x7330) [0x7f05b37b6330]
#4: [0x7f05b37b86f0] /usr/lib64/asterisk/modules/res_stasis.so(stasis_app_subscribe+0x1a0) [0x7f05b37b86f0]
#5: [0x7f05946e3de9] /usr/lib64/asterisk/modules/res_ari_applications.so(+0x1de9) [0x7f05946e3de9]
#6: [0x7f05946e3759] /usr/lib64/asterisk/modules/res_ari_applications.so(+0x1759) [0x7f05946e3759]
#7: [0x7f05caff0d0a] /usr/lib64/asterisk/modules/res_ari.so(ast_ari_invoke+0x34a) [0x7f05caff0d0a]
#8: [0x7f05caff1ec1] /usr/lib64/asterisk/modules/res_ari.so(+0x6ec1) [0x7f05caff1ec1]
#9: [0x5240ac] /usr/sbin/asterisk() [0x5240ac]
#10: [0x524619] /usr/sbin/asterisk() [0x524619]
#11: [0x5d89ad] /usr/sbin/asterisk() [0x5d89ad]
#12: [0x5e791a] /usr/sbin/asterisk() [0x5e791a]

QUESTION
Is this a known bug? What should I try to do to avoid that problem?
It seems like a concurrency issue.
How can I narrow down this problem?

There might be some additional information available by compiling Asterisk with no optimizations, and then running Asterisk with the -g parameter and forcing the crash. Or has this been done already?

Yeah if you can reproduce the issue, follow the instructions on getting a backtrace…
https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace

Then open an issue at https://issues.asterisk.org

Thanks a lot,
I will try to get that additional information.