[asterisk-bugs] [JIRA] (ASTERISK-26043) core: Crash when notifying threadpool listener
Javier Riveros (JIRA)
noreply at issues.asterisk.org
Wed Jun 1 12:06:56 CDT 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-26043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=230872#comment-230872 ]
Javier Riveros edited comment on ASTERISK-26043 at 6/1/16 12:05 PM:
---------------------------------------------------------------------
Hey Guys I get more clear Full/coredumps {{full_new.log and gdb_new.txt}} logs this has the SIP traces so is more clear to see the what type of call make it crash, it was a PSTN -> WebRTC call the call was setup fine but at the time the call is hangup by the Caller and leaving the bridge it is when the {{threadpool_send_state_changed}} make asterisk crash.
This is how i have the pjsip.conf file just in case.
{noformat}
[transport_simple_tcp]
type=transport
protocol=tcp
bind=0.0.0.0
external_media_address=xx.xx.xx.xx
[transport_simple_udp]
type=transport
protocol=udp
bind=0.0.0.0
external_media_address=xx.xx.xx.xx
[aor_proxy_udp]
type=aor
contact=sip:proxy.somedomain.com
qualify_frequency=30
; AOR to dial endpoints with TCP/webrtc
[aor_proxy_tcp]
type=aor
contact=sip:proxy.somedomain.com\;transport=tcp
qualify_frequency=30
[sip-standard]
type=endpoint
context=default
disallow=all
allow=ulaw
allow=alaw
aors=aor_proxy_udp
direct_media=no
rtp_symmetric=yes
media_address=xx.xx.xx.xx
force_rport=yes
media_encryption=no
ice_support=no
media_use_received_transport=yes
timers=no
[sip-webrtc]
type=endpoint
context=default
allow=ulaw
allow=alaw
aors=aor_proxy_tcp
direct_media=no
rtp_symmetric=yes
media_address=xx.xx.xx.xx
force_rport=yes
use_avpf=yes
ice_support=yes
media_encryption=dtls
dtls_setup=actpass
dtls_verify=fingerprint
dtls_cert_file=/etc/ssl/star.somedomain.com/cert.pem
dtls_private_key=/etc/ssl/star.somedomain.com/key.pem
media_use_received_transport=yes
timers=no
timers_sess_expires=90
timers_min_se=90
{noformat}
I though this is good information for the ticket :)
*note* this new coredumps files were with 13.9.1 version
was (Author: goseeped):
Hey Guys I get more clear Full/coredumps {{full_new.log and gdb_new.txt}} logs this has the SIP traces so is more clear to see the what type of call make it crash, it was a PSTN -> WebRTC call the call was setup fine but at the time the call is hangup by the Caller and leaving the bridge it is when the {{threadpool_send_state_changed}} make asterisk crash.
This is how i have the pjsip.conf file just in case.
{noformat}
[transport_simple_tcp]
type=transport
protocol=tcp
bind=0.0.0.0
external_media_address=xx.xx.xx.xx
[transport_simple_udp]
type=transport
protocol=udp
bind=0.0.0.0
external_media_address=xx.xx.xx.xx
[aor_proxy_udp]
type=aor
contact=sip:proxy.somedomain.com
qualify_frequency=30
; AOR to dial endpoints with TCP/webrtc
[aor_proxy_tcp]
type=aor
contact=sip:proxy.somedomain.com\;transport=tcp
qualify_frequency=30
[sip-standard]
type=endpoint
context=default
disallow=all
allow=ulaw
allow=alaw
aors=aor_proxy_udp
direct_media=no
rtp_symmetric=yes
media_address=xx.xx.xx.xx
force_rport=yes
media_encryption=no
ice_support=no
media_use_received_transport=yes
timers=no
[sip-webrtc]
type=endpoint
context=default
allow=ulaw
allow=alaw
aors=aor_proxy_tcp
direct_media=no
rtp_symmetric=yes
media_address=xx.xx.xx.xx
force_rport=yes
use_avpf=yes
ice_support=yes
media_encryption=dtls
dtls_setup=actpass
dtls_verify=fingerprint
dtls_cert_file=/etc/ssl/star.somedomain.com/cert.pem
dtls_private_key=/etc/ssl/star.somedomain.com/key.pem
media_use_received_transport=yes
timers=no
timers_sess_expires=90
timers_min_se=90
{noformat}
I though this is good information for the ticket :)
> core: Crash when notifying threadpool listener
> ----------------------------------------------
>
> Key: ASTERISK-26043
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-26043
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/General
> Affects Versions: 13.8.0, 13.9.1
> Reporter: Javier Riveros
> Assignee: Unassigned
> Attachments: asterisk_core_crash.zip, full_new.log, gdb_new.txt
>
>
> Im getting ramdom crashs in my asterisk boxes, at this point i try to dig what type of call make it happen but i don't have any clue what is happening here, i collect the proper core dumps and logs in other to determine what is going here,
> I can say that 99% of my calls are to ARI/stasis app.
> you will see a coredumps like this :
> {noformat}
> #0 0x00000000005eb3e4 in threadpool_send_state_changed (pool=0x7fa2c40393b0)
> at threadpool.c:185
> #0 0x00000000005eb3e4 in threadpool_send_state_changed (pool=0x7fa2c40393b0)
> at threadpool.c:185
> #1 0x00000000005eb506 in queued_active_thread_idle (data=0x7fa2c41d3148)
> at threadpool.c:241
> #2 0x00000000005e411b in ast_taskprocessor_execute (tps=0x2a40ed8)
> at taskprocessor.c:850
> #3 0x00000000005e2803 in default_tps_processing_function (data=0x2a40e58)
> at taskprocessor.c:183
> #4 0x00000000005f8fab in dummy_start (data=0x2a40720) at utils.c:1237
> #5 0x00007fa3108b3182 in start_thread (arg=0x7fa30c17d700)
> at pthread_create.c:312
> #6 0x00007fa30fb7347d in clone ()
> at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> #0 0x00000000005eb3e4 in threadpool_send_state_changed (pool=0x7fa2c40393b0)
> at threadpool.c:185
> active_size = 1246756870
> idle_size = 825112882
> #1 0x00000000005eb506 in queued_active_thread_idle (data=0x7fa2c41d3148)
> at threadpool.c:241
> pair = 0x7fa2c41d3148
> #2 0x00000000005e411b in ast_taskprocessor_execute (tps=0x2a40ed8)
> at taskprocessor.c:850
> local = {local_data = 0x24500000020, data = 0x2a3b280}
> t = 0x7fa2c4210f60
> size = 6170346
> __PRETTY_FUNCTION__ = "ast_taskprocessor_execute"
> #3 0x00000000005e2803 in default_tps_processing_function (data=0x2a40e58)
> at taskprocessor.c:183
> listener = 0x2a40e58
> tps = 0x2a40ed8
> pvt = 0x2a3b270
> sem_value = 202886864
> res = 0
> __PRETTY_FUNCTION__ = "default_tps_processing_function"
> #4 0x00000000005f8fab in dummy_start (data=0x2a40720) at utils.c:1237
> __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {
> 140338259285760, -2854846373934348535, 0, 0, 140338259286464,
> 140338259285760, -2854846373942737143, 2821387285705049865},
> __mask_was_saved = 0}}, __pad = {0x7fa30c17cef0, 0x0, 0x0, 0x0}}
> __cancel_routine = 0x450d23 <ast_unregister_thread>
> __cancel_arg = 0x7fa30c17d700
> __not_first_call = 0
> ret = 0x0
> a = {start_routine = 0x5e276d <default_tps_processing_function>,
> data = 0x2a40e58,
> name = 0x2a3c300 "default_tps_processing_function started at [ 200] taskprocessor.c default_listener_start()"}
> #5 0x00007fa3108b3182 in start_thread (arg=0x7fa30c17d700)
> at pthread_create.c:312
> __res = <optimized out>
> pd = 0x7fa30c17d700
> now = <optimized out>
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140338259285760,
> {noformat}
> *note:* sometimes the crash doesn't dump core files.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list