Segfault in ExternalIVR()

I’m a long-time programmer but am just an Asterisk user. I’ve tracked down a segfault that is clearly a bug, but don’t know where the best place to post is. If anyone has feedback on this, please let me know.

This bug appears to be a race condition in the ExternalIVR().

Entire dialplan:

The argument is the pathname of a Python file, which in it’s entirety is:

import sys
import time

Call the single extension 70 from a SIP phone. Result, segfault. Partial backtrace is below.

If, in the python code above, the time.sleep(1) is decommented, it works fine.

The problem appears to be this: app_exec() (which is in app_externalivr.c) creates the ivr_localuser (the pointer to which is often referred to as u). It does not initialize the playing_silence field of that struct. It then calls ast_activate_generator(), passing in that struct to be passed back to the handlers such as gen_generate(). ast_activate_generator() does an ast_settimeout(), which, near as I can tell, causes generator_force() to be called on a different thread. generator_force() calls the above-mentioned gen_generate(), which ultimately calls gen_nextfile(). It is gen_nextfile() that sets or clears the u->playingsilence field. Meanwhile, app_exec() has called eivr_comm(). This function gets the first file to play from the Python script above. In processing that command–look for EIVR_CMD_SQUE–it checks both u->abort_current_sound and u->playing_silence. However, playing_silence is false not having yet been set by gen_nextfile(). So the code tries to send a T event to the Python script even though there is nothing being played. It chokes on the send_eivr_event() call because the entry->filename parameter is not valid.

Probably should just init playing_silence when abort_current_sound is initialized in app_exec().

Core was generated by `asterisk -gc'. Program terminated with signal 11, Segmentation fault. #0 0x009d81d3 in strlen () from /lib/ (gdb) bt #0 0x009d81d3 in strlen () from /lib/ #1 0x009a7c0e in vfprintf () from /lib/ #2 0x009c83f4 in vsnprintf () from /lib/ #3 0x0817e5b5 in __ast_str_helper (buf=0xb7a18580, max_len=0, append=1, fmt=0x13e1f8 ",%s", ap=0xb7a1855c "\004") at strings.c:72 #4 0x0818fb26 in ast_str_append_va (buf=0xb7a18580, max_len=0, fmt=0x13e1f8 ",%s", ap=0xb7a1855c "\004") at /home/steve/projects/asterisk/asterisk-1.8.0/include/asterisk/strings.h:787 #5 0x0818fc68 in ast_str_append (buf=0xb7a18580, max_len=0, fmt=0x13e1f8 ",%s") at /home/steve/projects/asterisk/asterisk-1.8.0/include/asterisk/strings.h:859 #6 0x0013a4f8 in send_eivr_event (handle=0xb7c0e9c8, event=84 'T', data=0x4 <Address 0x4 out of bounds>, chan=0x88d6ec0) at app_externalivr.c:160 #7 0x0013d0d1 in eivr_comm (chan=0x88d6ec0, u=0xb7a19ab4, eivr_events_fd=0xb7a1ab3c, eivr_commands_fd=0xb7a1ab30, eivr_errors_fd=0xb7a1ab28, args=0xb7a192f0, flags=...) at app_externalivr.c:766 #8 0x0013c028 in app_exec (chan=0x88d6ec0, data=0xb7a1cd58 "/var/lib/asterisk/agi-bin/") at app_externalivr.c:559 #9 0x08132516 in pbx_exec (c=0x88d6ec0, app=0x8892de0, data=0xb7a1cd58 "/var/lib/asterisk/agi-bin/") at pbx.c:1399 #10 0x0813b7f2 in pbx_extension_helper (c=0x88d6ec0, con=0x0, context=0x88d722c "internal", exten=0x88d727c "70", priority=1, label=0x0, callerid=0x88cca50 "73", action=E_SPAWN, found=0xb7a1f25c, combined_find_spawn=1) at pbx.c:4078 #11 0x0813d07b in ast_spawn_extension (c=0x88d6ec0, context=0x88d722c "internal", exten=0x88d727c "70", priority=1, callerid=0x88cca50 "73", found=0xb7a1f25c, combined_find_spawn=1) at pbx.c:4577 #12 0x0813da03 in __ast_pbx_run (c=0x88d6ec0, args=0x0) at pbx.c:4675 #13 0x0813f4b1 in pbx_thread (data=0x88d6ec0) at pbx.c:4986 #14 0x0819056a in dummy_start (data=0x88d9828) at utils.c:971 #15 0x00ace832 in start_thread () from /lib/ #16 0x00a39e0e in clone () from /lib/

I should have said that this is in 1.8.0.


Best place to post is the issue tracker:

We’ve got our debugging guidlines here:

that should help you with your issue report.

Thank you. :smile:

This is reported as issue 18430. It appears it will be fixed shortly.