20.17.0 crash after format_cap.c fracks, not happenign on 20.15.2

Asterisk Asterisk SIP
1

Upon upgrading 2-3 different Ubuntu 24 Azure VM servers from v20.15.2 to 20.17.0, each one started to show fracks froim format_cap.c in some of the following symptoms:

[2025-12-11 15:48:09] ERROR[1973123] format_cap.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x618a84ed4328 (0)
[2025-12-11 15:48:09] ERROR[1973123] : Got 17 backtrace records
# 0: /usr/sbin/asterisk(__ao2_ref+0x5ea) [0x618a6391e00a]
# 1: /usr/sbin/asterisk(__ao2_ref+0xa5) [0x618a6391dac5]
# 2: /usr/sbin/asterisk(+0x10bde3) [0x618a639b7de3]
# 3: /usr/sbin/asterisk(__ao2_ref+0xa5) [0x618a6391dac5]
# 4: /usr/sbin/asterisk(ast_channel_nativeformats_set+0xac) [0x618a6397c1fc]
# 5: /usr/sbin/asterisk(+0xb4c9a) [0x618a63960c9a]
# 6: /usr/sbin/asterisk(__ao2_ref+0xa5) [0x618a6391dac5]
# 7: /usr/lib/asterisk/modules/chan_pjsip.so(+0x975c) [0x7ac9352a075c]
# 8: /usr/sbin/asterisk(__ao2_ref+0xa5) [0x618a6391dac5]
# 9: /usr/lib/asterisk/modules/chan_pjsip.so(+0x12c3e) [0x7ac9352a9c3e]
#10: /usr/sbin/asterisk(ast_taskprocessor_execute+0xe7) [0x618a63a759b7]
#11: /usr/sbin/asterisk(+0x1d0390) [0x618a63a7c390]
#12: /usr/sbin/asterisk(ast_taskprocessor_execute+0xe7) [0x618a63a759b7]
#13: /usr/sbin/asterisk(+0x1d0e6f) [0x618a63a7ce6f]
#14: /usr/sbin/asterisk(+0x1d8c26) [0x618a63a84c26]
#15: /lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7ac938a94ac3]
#16: /lib/x86_64-linux-gnu/libc.so.6(+0x1268c0) [0x7ac938b268c0]

or

[2025-12-11 16:28:48] ERROR[670001] format_cap.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x58a14fa265b8 (0)
[2025-12-11 16:28:48] ERROR[670001] : Got 19 backtrace records
# 0: /usr/sbin/asterisk(__ao2_ref+0x5ea) [0x58a13a45000a]
# 1: /usr/sbin/asterisk(__ao2_ref+0xa5) [0x58a13a44fac5]
# 2: /usr/sbin/asterisk(+0x10bde3) [0x58a13a4e9de3]
# 3: /usr/sbin/asterisk(__ao2_ref+0xa5) [0x58a13a44fac5]
# 4: /usr/sbin/asterisk(+0x1c06f6) [0x58a13a59e6f6]
# 5: /usr/sbin/asterisk(__ao2_ref+0xa5) [0x58a13a44fac5]
# 6: /usr/lib/asterisk/modules/res_pjsip.so(+0x36469) [0x7293e3ead469]
# 7: /usr/sbin/asterisk(+0x19aee6) [0x58a13a578ee6]
# 8: /usr/sbin/asterisk(__ao2_ref+0xa5) [0x58a13a44fac5]
# 9: /usr/lib/asterisk/modules/res_pjsip_session.so(+0xf92f) [0x7293e3d9e92f]
#10: /usr/sbin/asterisk(__ao2_ref+0xa5) [0x58a13a44fac5]
#11: /usr/lib/asterisk/modules/res_pjsip_session.so(+0x92d3) [0x7293e3d982d3]
#12: /usr/sbin/asterisk(ast_taskprocessor_execute+0xe7) [0x58a13a5a79b7]
#13: /usr/sbin/asterisk(+0x1d0390) [0x58a13a5ae390]
#14: /usr/sbin/asterisk(ast_taskprocessor_execute+0xe7) [0x58a13a5a79b7]
#15: /usr/sbin/asterisk(+0x1d0e6f) [0x58a13a5aee6f]
#16: /usr/sbin/asterisk(+0x1d8c26) [0x58a13a5b6c26]
#17: /lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x729423294ac3]
#18: /lib/x86_64-linux-gnu/libc.so.6(+0x1268c0) [0x7294233268c0]

The stack is not always exactly the same but the pjsip module and format_cap.c is a common point.

Have a local postgres via UNIX socket for pjsip realtime storage, and an ARI app for control.

When the server handles no calls, the issue does not happen, but can easily be reproed in a handful of call attempts.

Are using v20 versions since around 20.11 or so with this very setup and have not seen such before.

Did not (yet) open a gh issue as I assumed it is so prevalent that a lot of others have surely reported it? But … no?

2

There have been no reports. You’d need to provide further information such as the codecs in use, configuration, and the SIP/SDP to show the negotiation.

3

Given I can repro with sipp, the SDP is pretty basic

12/11/2025 18:08:59.338 +01:00: 10.0.22.37:5060 -> 10.0.22.40:5060
INVITE sip:+361555175@10.0.22.40:5060 SIP/2.0
Via:  SIP/2.0/UDP 10.0.22.37:5060;branch=z9hG4bK-2256-15-0
From:  sipp <sip:JEJ170819@10.0.22.40>;tag=15
To:  <sip:XXXredactedXXX@10.0.22.40:5060>
Call-ID: 15-2256@10.0.22.37
CSeq:  1 INVITE
Contact:  sip:JEJ170819@10.0.22.37:5060
Max-Forwards:  10
OrganizationID:  69315ecf766d9ae0e0402f05
Content-Type:  application/sdp
Content-Length:    131

v=0
o=user1 53655765 2353687637 IN IP4 10.0.22.37
s=-
c=IN IP4 10.0.22.37
t=0 0
m=audio 6000 RTP/AVP 8
a=rtpmap:8 PCMA/8000

It does not falter right at the first message, but fairly soon.

4

Still all good here, and I’ve been throwing tons of calls at things as has the testsuite.

I’d suggest creating an issue with step by step instructions and explicit configuration that reproduces the issue and seeing if the person on triage can reproduce it, or they may ask for additional information.

1 Like
5

Thanks @jcolp, will do that.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.