[Home]

Summary:ASTERISK-25201: Crash in PJSIP distributor on already free'd threadpool
Reporter:Matt Jordan (mjordan)Labels:
Date Opened:2015-06-25 06:34:37Date Closed:2015-07-27 11:32:36
Priority:MajorRegression?
Status:Closed/CompleteComponents:Core/General Resources/res_pjsip
Versions:13.4.0 Frequency of
Occurrence
Related
Issues:
is related toASTERISK-25183 PJSIP: Crash on NULL channel in chan_pjsip_incoming_response despite previous checks for NULL channel
Environment:Attachments:( 0) backtrace_1191.txt
( 1) full.txt
( 2) messages.txt
Description:One of the tests in the Testsuite (channels/pjsip/transfers/attended_transfer/nominal/caller_local_direct_media) crashed in a rather interesting location - on an ao2 object which was {{0xdeaddead}}. It appears as if this is the PJSIP threadpool that a taskprocessor was attempting to use:

{code}
#0  0x0000000000480f86 in __ao2_lock (user_data=0xdeaddeaddeaddead, lock_how=AO2_LOCK_REQ_MUTEX, file=0x87aa00 "threadpool.c", func=0x87add0 "ast_threadpool_push", line=898, var=0x87aa11 "((pool))") at astobj2.c:187
187 struct astobj2 *obj = __INTERNAL_OBJ_CHECK(user_data, file, line, func);
#0  0x0000000000480f86 in __ao2_lock (user_data=0xdeaddeaddeaddead, lock_how=AO2_LOCK_REQ_MUTEX, file=0x87aa00 "threadpool.c", func=0x87add0 "ast_threadpool_push", line=898, var=0x87aa11 "((pool))") at astobj2.c:187
       p__LINE__ = 0xdeaddeaddeadde85
       obj = 0x877b83
       obj_mutex = 0x100000002
       obj_rwlock = 0x0
       res = 32588
       __PRETTY_FUNCTION__ = "__ao2_lock"
#1  0x00000000007532b6 in ast_threadpool_push (pool=0xdeaddeaddeaddead, task=0x7540a3 <execute_tasks>, data=0x7f4c40021e20) at threadpool.c:898
       lock = 0x73ef56
       __PRETTY_FUNCTION__ = "ast_threadpool_push"
#2  0x00000000007541f5 in serializer_task_pushed (listener=0x7f4c40021d00, was_empty=1) at threadpool.c:1175
       ser = 0x7f4c40021bf8
       tps = 0x7f4c40021e20
{code}

Logs and backtrace attached.
Comments:By: Richard Mudgett (rmudgett) 2015-06-25 09:32:11.611-0500

I'm guessing that this is a ref counting issue with the serializer.
By: Asterisk Team (asteriskteam) 2015-07-26 11:53:14.958-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.