Asterisk shutsdown segfault at 10 ip ... error 4 in app_queue.so

Hi. This may be a possible memory leak but I haven’t had any luck trying to solve this.

I’m using Asterisk 13.17 and this is the scenario:

Asterisk accepts a call through an E1 PRI and enters to a QueueA, the call is answered by an AgentA (sip_chan), this agent makes an attended transfer to dial plan and listen to an announce, the AgentA hangs up leaving the current channel and the caller connected, the call goes to a QueueB… and then Asterisk breaks. No warnings.

in /var/log/messages I get

kerberus kernel: [818513.936980] asterisk[59949]: segfault at 10 ip 00007fdbead35b1c sp 00007fdbd50efd00 error 4 in app_queue.so[7fdbead13000+39000]

It happens when there’s about 5 situations like the mentioned.

1 Like

Please follow the instructions on the wiki[1] to get a backtrace from this so we can see why it crashed.

[1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace

Thank you for the reply, I’ll recompile by night and get asterisk ready to make core files if it fails.

Hi jcolp, I got the core files

http://kerberus.com.co/core/core.kerberus-2017-07-28T08-51-29-0500-full.txt

http://kerberus.com.co/core/core.kerberus-2017-07-28T08-51-29-0500-thread1.txt

http://kerberus.com.co/core/core.kerberus-2017-07-28T08-51-29-0500-brief.txt

http://kerberus.com.co/core/core.kerberus-2017-07-28T08-51-29-0500-locks.txt

Are you sure you are using Asterisk 13.17.0? The line numbers in your backtrace don’t match up.

Hi, no,last night I installed Asterisk 14.6, I’m sorry for not mention.

The line numbers still don’t seem to line up. Have you made any modifications and can you confirm for sure what is installed and what the backtrace is from?

Hi, jcolp.

I have an update; we move back to 13.17, 2. and we have a clear scenario now.

  1. Call enters to a Queue A and is received by Agent A
  2. Agent A executes an attended transfer to a Queue B and hangs up before someone answers
  3. The trasnfered call is not answered since Queue B has callback agents and none answers.
  4. The attended transfer fails (beeperr) but the original channel had been optimized.
  5. Asterisk stops.

I guess the problem is since Queue B has no an Answer() command, the attended transfer fails and Asterisk has no idea to where return the call. So we are going to test adding the Answer command and see what happens.

By the way, I have the cores files for 13.17:

http://kerberus.com.co/core/core.kerberus-2017-07-31T08-40-49-0500-full.txt
http://kerberus.com.co/core/core.kerberus-2017-07-31T08-40-49-0500-thread1.txt

Yes, now that line numbers match up I can see where it is crashing - data is missing that is expected to be there. You can file an issue[1] with the details.

[1] https://issues.asterisk.org/jira

Just a note:

Related issues are 27166 and 27006
https://issues.asterisk.org/jira/browse/ASTERISK-27006