3 thoughts on - Asterisk 13.15.0 Stopping/crashing

• when run from console without systemd i found its segfaulting

  turned core dump on because it was off

  Dne 09/05/2017 v 13:52 marek cervenka napsal(a):

• i can upgrade asterisk to DONT_OPTIMIZE version at night

  before that, do you see something strange?

  is it known issue?

  [Thread debugging using libthread_db enabled]
  Using host libthread_db library “/lib64/libthread_db.so.1”. Core was generated by `/usr/sbin/asterisk -f -C
  /etc/asterisk/asterisk.conf’. Program terminated with signal 11, Segmentation fault.
  #0 pj_lock_acquire (lock=0xc3d2e1f010325476) at ../src/pj/lock.c:180
  180 return (*lock->acquire)(lock->lock_object);
  #0 pj_lock_acquire (lock=0xc3d2e1f010325476) at ../src/pj/lock.c:180
  lock = 0xc3d2e1f010325476
  #1 0x00007f1a206b1f51 in grp_lock_acquire (p=0x7f19e0408dc8) at
  ../src/pj/lock.c:290
  glock = 0x7f19e0408dc8
  lck = 0x7f1a18009a18
  #2 pj_grp_lock_acquire (grp_lock=0x7f19e0408dc8) at ../src/pj/lock.c:478
  No locals.
  #3 0x00007f1a20646b6c in pjsip_tsx_send_msg (tsx=0x7f19e042f7b8, tdata=tdata@entry=0x7f1a04004378) at ../src/pjsip/sip_transaction.c:1743
  event = {prev = 0x7f1a04004e88, next = 0x7f1a040043b8, type PJSIP_EVENT_TX_MSG, body = {timer = {entry = 0x7f1a04004378}, tsx_state
  = {src = {rdata = 0x7f1a04004378, tdata = 0x7f1a04004378, timer 0x7f1a04004378, status = 67126136, data = 0x7f1a04004378}, tsx 0x7f1a04004378, prev_state = 67126136, type = 32538}, tx_msg = {tdata 0x7f1a04004378}, tx_error = {tdata = 0x7f1a04004378, tsx 0x7f1a04004378}, rx_msg = {rdata = 0x7f1a04004378}, user = {user1 0x7f1a04004378, user2 = 0x7f1a04004378, user3 = 0x7f1a04004378, user4 0x7f1a180153a8}}}
  status =
  #4 0x00007f19f57ff7a5 in ast_sip_send_stateful_response
  (rdata=rdata@entry=0x7f1a180153a8, tdata=0x7f1a04004378, sip_endpoint=sip_endpoint@entry=0x7f1a1802ead8) at res_pjsip.c:4323
  tsx = 0x7f19e042f7b8
  #5 0x00007f19b3dae7e8 in register_aor_core
  (rdata=rdata@entry=0x7f1a180153a8, endpoint=endpoint@entry=0x7f1a1802ead8, aor=aor@entry=0x7f1a18019bb8, aor_name=aor_name@entry=0x7f1a1801a250 “webrtc_kalabek”, contacts=0x7f1a180148c8, contacts@entry=0x7f1a18019ca8) at res_pjsip_registrar.c:535
  USER_AGENT = {ptr = 0x7f19b3daeed2 “User-Agent”, slen = 10}
  added =
  updated =
  deleted =
  contact_hdr =
  details = {pool = 0x7f1a180024e0, uri = 0x7f1a18005b38}
  tdata = 0x7f1a04004378
  path_str = 0x0
  response_contact =
  user_agent =
  user_agent_hdr =
  expires_hdr =
  via_hdr =
  via_hdr_last =
  via_addr =
  via_port =
  call_id_hdr =
  call_id = 0x7f19a9c24890 “ali2f0j4fir96pl1uic74h”
  alloc_size =
  __PRETTY_FUNCTION__ = “register_aor_core”
  #6 0x00007f19b3daec2c in register_aor (aor_name=0x7f1a1801a250
  “webrtc_kalabek”, aor=0x7f1a18019bb8, endpoint=0x7f1a1802ead8, rdata=0x7f1a180153a8) at res_pjsip_registrar.c:562
  contacts = 0x7f1a18019ca8
  lock = 0x7f1a18019b60
  #7 registrar_on_rx_request (rdata=0x7f1a180153a8) at res_pjsip_registrar.c:747
  endpoint = 0x7f1a1802ead8
  aor = 0x7f1a18019bb8
  aor_name = 0x7f1a1801a250 “webrtc_kalabek”
  __PRETTY_FUNCTION__ = “registrar_on_rx_request”
  #8 0x00007f1a2062ce47 in pjsip_endpt_process_rx_data (endpt=, rdata=rdata@entry=0x7f1a180153a8, p=p@entry=0x7f19f5a2fbe0 , p_handled=p_handled@entry=0x7f19a9c24c44) at
  ../src/pjsip/sip_endpoint.c:887
  msg = 0x7f1a18016e70
  def_prm = {start_prio = 2846042224, start_mod = 0x36c, idx_after_start = 3825613152, silent = 32537}
  mod = 0x7f19b3fb13a0
  handled = 0
  i =
  status =
  #9 0x00007f19f580ab31 in distribute (data=0x7f1a180153a8) at res_pjsip/pjsip_distributor.c:770
  param = {start_prio = 0, start_mod = 0x7f19f5a2fe00
  , idx_after_start = 1, silent = 0}
  handled = 0
  rdata = 0x7f1a180153a8
  is_request = 1
  is_ack = 0
  endpoint =
  #10 0x00000000005de7ce in ast_taskprocessor_execute
  (tps=tps@entry=0x3afcdc0) at taskprocessor.c:965
  local = {local_data = 0x7f1a1e8a0c53 <_L_unlock_697+15>, data 0xea53c1a939bfe600}
  t = 0x7f1a1800a1b0
  size =
  __PRETTY_FUNCTION__ = “ast_taskprocessor_execute”
  #11 0x00000000005e5fe0 in execute_tasks (data=0x3afcdc0) at threadpool.c:1322
  tps = 0x3afcdc0
  #12 0x00000000005de7ce in ast_taskprocessor_execute (tps=0x2f70570) at taskprocessor.c:965
  local = {local_data = 0x7f1a1800ae38, data = 0x2}
  t = 0x7f1a18013c60
  size =
  __PRETTY_FUNCTION__ = “ast_taskprocessor_execute”
  #13 0x00000000005e6978 in threadpool_execute (pool=0x2f6ef20) at threadpool.c:351
  No locals.
  #14 worker_active (worker=0x7f1a1800ae00) at threadpool.c:1105
  No locals.
  #15 worker_start (arg=arg@entry=0x7f1a1800ae00) at threadpool.c:1024
  worker = 0x7f1a1800ae00
  saved_state =
  __PRETTY_FUNCTION__ = “worker_start”
  #16 0x00000000005f03fe in dummy_start (data=) at utils.c:1235
  __clframe = {__cancel_routine = , __cancel_arg 0x7f19a9c25700, __do_it = 1, __cancel_type = }
  ret =
  a = {start_routine = 0x5e65e0 , data 0x7f1a1800ae00, name = }
  #17 0x00007f1a1e89ddc5 in start_thread () from /lib64/libpthread.so.0
  No symbol table info available.
  #18 0x00007f1a1db7d73d in clone () from /lib64/libc.so.6
  No symbol table info available.

  Dne 09/05/2017 v 14:57 marek cervenka napsal(a):

• The only issue that looks like it could be related is ASTERISK-26969[1]. Once you have an unoptimized backtrace though go ahead and file an issue[2].

  [1] https://issues.asterisk.org/jira/browse/ASTERISK-26969
  [2] https://issues.asterisk.org/jira