Segfault ast_json_vpack JSON Parse UTF-8 ▒▒

Hello,

I’m currently using Asterisk 19.1.0.
I encountered this issue with Asterisk 17.x as well.

My Logs show there is a JSON Parse exception. This crash occurs when entering and leaving ConfBridge Application and when inviting a participant to a ConfBridge. I have been trying to trace this down. I believe that it might be something with the Channel Application and Channel Data becoming empty, and perhaps the ‘\0’ character is not interpreted correctly thus causing Segmentation Faults.

I can also see this on a one-to-one call. However, the one-to-one call does not cause Segmentation Faults. This occurs when I use the b() option within Dial Command. The outbound channel does not properly set the Channel Application and Channel Data.

An example is this:
Dev1Asterisk1*CLI> core show channels
Channel Location State Application(Data)
PJSIP/opensips_noweb 11e6f5a0-4ccd-424a-a Ring Dial(PJSIP/11e6f5a0-4ccd-424a-
PJSIP/11e6f5a0-4ccd- 11e6f5a0-4ccd-424a-a Ringing ▒+=▒(▒+=▒)

I used Asterisk 15.5 for a few years and never saw the ▒ character in one-to-one calls. It started occuring when I upgraded to 17.x then to 19.1.0. I have reason to believe this might be related to the Conference Segmentation Fault.
Has anyone encountered this before?

Conference Segmentation Fault CLI Logs:
[2022-08-16 20:59:38] ERROR[2694078][C-00000004]: json.c:636 ast_json_dialplan_cep_app: TRUJILLO Context=‘users’: exten=C947 : priority=20 : app_name=▒o:U^▒▒▒▒R9J▒:▒▒▒▒&Ls▒▒▒9▒s▒8\▒M:▒U:▒,▒▒
▒▒۹!^▒7▒▒▒:▒▒`:▒3=▒▒֋▒▒E/:▒▒:▒li:V▒▒h▒ڸ▒▒p:▒▒y9▒▒9▒<j▒r:▒▒ٹ▒(▒▒▒▒▒8H▒▒▒-f▒UԢ9▒▒▒U9G▒P:!^▒8▒▒$:▒▒8u|▒5▒▒▒9▒▒:P癹▒▒▒▒▒,▒▒▒z:▒▒▒Ev▒T֬9=▒79('9▒kd▒K▒7:!k▒▒59▒ : app_data=▒▒o:▒,9S▒q▒1–▒.
[2022-08-16 20:59:38] ERROR[2694078][C-00000004]: json.c:607 ast_json_vpack: Error building JSON from ‘{s: s?, s: s?, s: o, s: s?, s: s?}’: Invalid UTF-8 string.
[2022-08-16 20:59:38] ERROR[2694078][C-00000004]: Got 23 backtrace records

0: asterisk/sbin/asterisk(ast_json_vpack+0xba) [0x50ff45]

1: asterisk/sbin/asterisk(ast_json_pack+0xa7) [0x50fe7b]

2: asterisk/sbin/asterisk(ast_json_dialplan_cep_app+0xb9) [0x5100a5]

3: asterisk/sbin/asterisk(ast_channel_snapshot_to_json+0xc7) [0x5abd57]

4: asterisk/lib/asterisk/modules/app_confbridge.so(+0x21b5f) [0x7f0b5c9dcb5f]

5: asterisk/lib/asterisk/modules/app_confbridge.so(+0x21dcb) [0x7f0b5c9dcdcb]

6: asterisk/lib/asterisk/modules/app_confbridge.so(+0x22797) [0x7f0b5c9dd797]

7: asterisk/lib/asterisk/modules/app_confbridge.so(+0x73ec) [0x7f0b5c9c23ec]

8: asterisk/lib/asterisk/modules/app_confbridge.so(+0x787e) [0x7f0b5c9c287e]

9: asterisk/lib/asterisk/modules/app_confbridge.so(+0xc73f) [0x7f0b5c9c773f]

#10: asterisk/sbin/asterisk() [0x48eeab]
#11: asterisk/sbin/asterisk(bridge_channel_internal_join+0x767) [0x48f6d8]
#12: asterisk/sbin/asterisk(ast_bridge_join+0x2c1) [0x473446]
#13: asterisk/lib/asterisk/modules/app_confbridge.so(+0xd3f6) [0x7f0b5c9c83f6]
#14: asterisk/sbin/asterisk(pbx_exec+0x119) [0x54b639]
#15: asterisk/lib/asterisk/modules/pbx_realtime.so(+0x2d7e) [0x7f0b5cffed7e]
#16: asterisk/sbin/asterisk() [0x537246]
#17: asterisk/sbin/asterisk(ast_spawn_extension+0x50) [0x53b0b1]
#18: asterisk/sbin/asterisk() [0x53bd63]
#19: asterisk/sbin/asterisk() [0x53d50e]
#20: asterisk/sbin/asterisk() [0x5d6f9c]
#21: /lib64/libpthread.so.0(+0x81cf) [0x7f0b5fc691cf]
#22: /lib64/libc.so.6(clone+0x43) [0x7f0b5f0f1dd3]

Thanks,
Carlos

I’d assume memory corruption, which may not cause a crash until some time after the initial error.

Please obtain a full crash dump backtrace as explained in:

https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace

Based on my experience with this, I’d say it’s not so much “memory corruption” as garbage data in a variable that ends up in the channel snapshot, i.e. the issue probably happens immediately rather than delayed.

This could be because a variable that is used isn’t initialized, and it’s thus filled with garbage. ▒ is very common when looking at uninitialized memory.

Either way, a bug, and a full backtrace is critical since that will contain more clues as to what the bad data/variables are.

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