Summary:	ASTERISK-26664: pjsip: pj_thread_register() assertion
Reporter:	Bernhard Schmidt (bschmidt)	Labels:
Date Opened:	2016-12-18 15:44:13.000-0600	Date Closed:
Priority:	Major	Regression?	Yes
Status:	Open/New	Components:	Channels/chan_pjsip
Versions:	13.13.0 13.13.1	Frequency of Occurrence	Constant
Related Issues:
Environment:	Linux, Debian unstable	Attachments:	( 0) paste_903006.txt
Description:	When a system pjproject library is used with assertions enabled (NDEBUG=0) answering an incoming call leads to the following assertion: {noformat} asterisk: ../src/pj/os_core_unix.c:692: pj_thread_this: Assertion `!"Calling pjlib from unknown/external thread. You must " "register external threads with pj_thread_register() " "before calling any pjlib functions."' failed. Aborted {noformat} This is caused by this commit: https://github.com/asterisk/asterisk/commit/2b9ad3a5f736b6a4081e172f2a6d35dcd20b51e4 A production build / embedded pjproject build does not fail since assertions are disabled there. But this still points to a programming error in chan_pjsip (as the assertion says, calling pjlib functions from an unregistered thread).
Comments:	By: Asterisk Team (asteriskteam) 2016-12-18 15:44:14.560-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Bernhard Schmidt (bschmidt) 2016-12-18 15:46:13.209-0600 GDB Backtrace By: Eddie Johnson (ejohnson) 2018-01-25 16:56:20.370-0600 I noticed this is pointing towards a Debian distro.  I am presently having the same issue with Centos 7 Server x86_64 1000/sip:1000@x.x.x.x:23311;transport=UDP;rinstance=5fc6b528c56c7b23 has been created == Endpoint 1000 is now Reachable – Contact 1000/sip:1000@x.x.x.x:23311;transport=UDP;rinstance=5fc6b528c56c7b23 is now Unknown. RTT: 0.000 msec – Added contact ‘sip:1001@x.x.x.x:46849;transport=UDP;rinstance=7759dbbfef6182fb’ to AOR ‘1001’ with expiration of 60 seconds == Contact 1001/sip:1001@x.x.x.x:46849;transport=UDP;rinstance=7759dbbfef6182fb has been created == Endpoint 1001 is now Reachable – Contact 1001/sip:1001@x.x.x.x:46849;transport=UDP;rinstance=7759dbbfef6182fb is now Unknown. RTT: 0.000 msec == Setting global variable ‘SIPDOMAIN’ to ‘x.x.x.x’asterisk (external IP) : …/src/pj/os_core_unix.c:692: pj_thread_this: Assertion `!"Calling pjlib from unknown/external thread. You must " "register external threads with pj_thread_register() " “before calling any pjlib functions.”’ failed.Aborted By: Timo Teräs (fabled) 2018-09-25 06:56:46.268-0500 I see this also on Alpine Linux. The gdb backtrace I have is: {quote} #0  0x000072e9689b1f6f in __syscall4 (a4=<optimized out>, a3=<optimized out>, a2=<optimized out>, a1=<optimized out>,    n=<optimized out>) at ./arch/x86_64/syscall_arch.h:38 #1  __restore_sigs (set=set@entry=0x72e9642adc20) at src/signal/block.c:43 #2  0x000072e9689b20d3 in raise (sig=sig@entry=6) at src/signal/raise.c:11 #3  0x000072e968989a77 in abort () at src/exit/abort.c:14 #4  0x000072e968989b33 in __assert_fail (expr=<optimized out>, file=<optimized out>, line=<optimized out>, func=<optimized out>)    at src/exit/assert.c:8 #5  0x000072e9662eeb89 in pj_thread_this () from /usr/lib/libpj.so.2 #6  0x000072e9662eed5b in pj_mutex_lock () from /usr/lib/libpj.so.2 #7  0x000072e9662ef0b8 in pj_atomic_inc_and_get () from /usr/lib/libpj.so.2 #8  0x000072e964fdf9a6 in pjsip_inv_add_ref () from /usr/lib/libpjsip-ua.so.2 #9  0x000072e964fa8259 in chan_pjsip_answer (ast=0x4ac10624b18) at chan_pjsip.c:720 #10 0x000004ac0dff11a9 in ast_raw_answer (chan=0x4ac10624b18) at channel.c:2710 #11 0x000004ac0dff5ca2 in __ast_answer (chan=chan@entry=0x4ac10624b18, delay=delay@entry=0) at channel.c:2732 #12 0x000004ac0dff5f2f in ast_answer (chan=chan@entry=0x4ac10624b18) at channel.c:2837 #13 0x000072e96678c329 in playback_exec (chan=0x4ac10624b18, data=<optimized out>) at app_playback.c:473 #14 0x000004ac0e07b80f in pbx_exec (c=c@entry=0x4ac10624b18, app=app@entry=0x4ac105d1160,    data=data@entry=0x4ac10660298 "vm-person&digits/3&digits/1&digits/3&digits/3&digits/7&vm-not_available_record_message")    at pbx_app.c:492 #15 0x000072e96675ffdb in lua_pbx_exec (L=0x4ac106224c0) at pbx_lua.c:233 #16 0x000072e96653f84c in ?? () from /usr/lib/liblua.so.5 #17 0x000072e966547d85 in ?? () from /usr/lib/liblua.so.5 #18 0x000072e96653f954 in ?? () from /usr/lib/liblua.so.5 #19 0x000072e96653ef22 in ?? () from /usr/lib/liblua.so.5 #20 0x000072e96653fa8e in ?? () from /usr/lib/liblua.so.5 #21 0x000072e96653c708 in lua_pcall () from /usr/lib/liblua.so.5 #22 0x000072e966760da4 in exec (chan=0x4ac10624b18, context=0x4ac106254d8 "default", exten=0x4ac10625528 "31337", priority=1,    callerid=<optimized out>, data=<optimized out>) at pbx_lua.c:1432 #23 0x000004ac0e0758c7 in pbx_extension_helper (c=c@entry=0x4ac10624b18, con=con@entry=0x0, context=<optimized out>,    exten=exten@entry=0x4ac10625528 "31337", priority=priority@entry=1, label=label@entry=0x0,    callerid=0x4ac105c2d80, action=E_SPAWN, found=0x72e9642b2924, combined_find_spawn=1) at pbx.c:2939 #24 0x000004ac0e07623d in ast_spawn_extension (c=c@entry=0x4ac10624b18, context=<optimized out>,    exten=exten@entry=0x4ac10625528 "31337", priority=priority@entry=1, callerid=callerid@entry=0x4ac105c2d80,    found=found@entry=0x72e9642b2924, combined_find_spawn=1) at pbx.c:4157 #25 0x000004ac0e076858 in __ast_pbx_run (c=c@entry=0x4ac10624b18, args=args@entry=0x0) at pbx.c:4331 #26 0x000004ac0e07794e in pbx_thread (data=data@entry=0x4ac10624b18) at pbx.c:4653 #27 0x000004ac0e0ceba8 in dummy_start (data=<optimized out>) at utils.c:1258 #28 0x000072e9689be95b in start (p=<optimized out>) at src/thread/pthread_create.c:147 {quote} By: Jørgen H (jorgen) 2018-10-04 04:49:17.778-0500 The recommended config_site.h from the Asterisk project to be used when building pjsip have the following definition #define PJ_OS_HAS_STACK_CHECK to 0 This will drop the calls to PJ_CHECK_STACK() which causes the assertion failures So the pjsip library is not built following Asterisk recommendations. The Asterisk patch causing the assertion failure should therefore be correct. However, pjsip 2.8 will fail on build/linking using asterisk config_site.h because the file removes srtp-support and there is a bug in pjsip including 2 functions it should have removed when not including srtp-support (srtpCryptoEnum() and pjmedia_srtp_enum_crypto() ) This bug is not related to Asterisk though.