Asterisk
  1. Asterisk
  2. ASTERISK-6768

Segfault on show channels after Agent is removed from Meetme

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Core/General
    • Labels:
      None
    • Source Revision Number:
      19466
    • Mantis ID:
      6952
    • Regression:
      No

      Description

      We are curently working on a inhouse predictive dialer solution, between 1.2.4 and 1.2.6/Head 19466 we noticed a number of critical changes:
      An Agent that is removed from a Meetme will not be getting any more calls (we use a redirect to take him out). Asterisk will become instantly unstable as in: show agents hangs the CLI, show channels segfaults, new manager connections are either denied or do not respond. I am able to reproduce the issue with HEAD 19466 as of today. We tried various other ways to remove the Agent from the conference but all end up without the agent getting ready to accept the next call.

                • ADDITIONAL INFORMATION ******

      Control and dialing is thru AMI, I can provide a complete log of the communication as well as the Asterisk console output.
      Workflow:
      Outbound calling:

      • Agentlogin thru Dial from AMI using Local/ Extension (a workaround to use channels would be major work and unfeasible because we have to have users connected to multiple servers)
      • AMI Programm dials from Channel (e.g. SIP/test/xxxxxxxxxxx or ZAP/g1/xxxxxxxxxx ) and directed to exten for queue.
      • Agent gets beep and is on call
      • AMIProgramm redirects Agent and external channel into Meetme
      • AMIProgramm Dials second Agentqueue into Meetme
      • AMIProgramm transfers first Agent out to Dialplan extension which plays wav and Hangs up

      ---> Agent is now reported to be ready to take new calls (Up) and sitting in app Agentlogin but calls are sitting in queue and system becomes unstable...

      1. AMI.log
        221 kB
      2. bt.txt
        0.4 kB
      3. btfull.txt
        4 kB
      4. console.txt
        35 kB
      5. gdb.txt
        19 kB
      6. new_crash_after_update_to_r21002M.txt
        25 kB
      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        Frank Waller added a comment -

        Hardware is Dual dualcore Opteron 4GB Ram running SuSE 10.0 (modified)
        running all in 64bit mode.

        Show
        Frank Waller added a comment - Hardware is Dual dualcore Opteron 4GB Ram running SuSE 10.0 (modified) running all in 64bit mode.
        Hide
        Frank Waller added a comment -

        After updating svn to the current version the problem is still there, but beside of that we see
        Apr 17 15:45:02 WARNING[18161]: channel.c:1642 ast_waitfor_nandfds: Thread 1082526048 Blocking 'Zap/pseudo-1228926242', already blocked by thread 1080928608 in procedure ast_waitfor_nandfds
        Apr 17 15:46:16 WARNING[18161]: chan_zap.c:4607 zt_read: Thread 1082526048 Blocking 'Zap/pseudo-1228926242', already blocked by thread 1082526048 in procedure ast_waitfor_nandfds
        Apr 17 15:48:18 WARNING[18162]: channel.c:1642 ast_waitfor_nandfds: Thread 1080928608 Blocking 'Zap/pseudo-1228926242', already blocked by thread 1082526048 in procedure ast_waitfor_nandfds
        Apr 17 15:49:05 WARNING[18162]: chan_zap.c:4607 zt_read: Thread 1080928608 Blocking 'Zap/pseudo-1228926242', already blocked by thread 1080928608 in procedure ast_waitfor_nandfds

        Warnings on the console.

        Any help would be greatly appreciated.

        Thanks in Advance

        Frank

        Show
        Frank Waller added a comment - After updating svn to the current version the problem is still there, but beside of that we see Apr 17 15:45:02 WARNING [18161] : channel.c:1642 ast_waitfor_nandfds: Thread 1082526048 Blocking 'Zap/pseudo-1228926242', already blocked by thread 1080928608 in procedure ast_waitfor_nandfds Apr 17 15:46:16 WARNING [18161] : chan_zap.c:4607 zt_read: Thread 1082526048 Blocking 'Zap/pseudo-1228926242', already blocked by thread 1082526048 in procedure ast_waitfor_nandfds Apr 17 15:48:18 WARNING [18162] : channel.c:1642 ast_waitfor_nandfds: Thread 1080928608 Blocking 'Zap/pseudo-1228926242', already blocked by thread 1082526048 in procedure ast_waitfor_nandfds Apr 17 15:49:05 WARNING [18162] : chan_zap.c:4607 zt_read: Thread 1080928608 Blocking 'Zap/pseudo-1228926242', already blocked by thread 1080928608 in procedure ast_waitfor_nandfds Warnings on the console. Any help would be greatly appreciated. Thanks in Advance Frank
        Hide
        Serge Vecher added a comment -

        explidous: can you please elaborate on the nature of your modifications to the Asterisk sources? Is it feasible to test with an unpatched SVN copy?

        Show
        Serge Vecher added a comment - explidous: can you please elaborate on the nature of your modifications to the Asterisk sources? Is it feasible to test with an unpatched SVN copy?
        Hide
        Frank Waller added a comment -

        Till about an hour ago I was running unpatched svn. All the postings here are from unpachted svn versions.
        I just patched it with the patch from 0006975, which seems to make my box not crash on every "show channel" after an Agent is take out of the meetme, still it does not work right yet.
        Agent is not available to take new calls after beeing remove from Meetme...

        Show
        Frank Waller added a comment - Till about an hour ago I was running unpatched svn. All the postings here are from unpachted svn versions. I just patched it with the patch from 0006975, which seems to make my box not crash on every "show channel" after an Agent is take out of the meetme, still it does not work right yet. Agent is not available to take new calls after beeing remove from Meetme...
        Hide
        Serge Vecher added a comment -

        explidous: there was an important fix committed earlier to file.c in both 1.2/trunk.

        Can you please test with latest unpatched trunk or 1.2 built with 'make dont-optimize' and produce a bt if the problem is still there. Thanks.

        Show
        Serge Vecher added a comment - explidous: there was an important fix committed earlier to file.c in both 1.2/trunk. Can you please test with latest unpatched trunk or 1.2 built with 'make dont-optimize' and produce a bt if the problem is still there. Thanks.
        Hide
        Frank Waller added a comment -

        I most likely can not retest before Monday, but as soon as our new development box is up I am going to update to svn-HEAD again to test it.

        Thanks

        Show
        Frank Waller added a comment - I most likely can not retest before Monday, but as soon as our new development box is up I am going to update to svn-HEAD again to test it. Thanks
        Hide
        Serge Vecher added a comment -

        please feel free to reopen if the problem still occurs in trunk with rev > 26000. Don't forget to attach a backtrace from non-optimized build.

        Show
        Serge Vecher added a comment - please feel free to reopen if the problem still occurs in trunk with rev > 26000. Don't forget to attach a backtrace from non-optimized build.

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development