[asterisk-bugs] [JIRA] (ASTERISK-27617) Frack (crash), excessive refcount during Jitterbuffer operation
Colin (JIRA)
noreply at issues.asterisk.org
Wed Jan 24 08:31:49 CST 2018
[ https://issues.asterisk.org/jira/browse/ASTERISK-27617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241775#comment-241775 ]
Colin commented on ASTERISK-27617:
----------------------------------
We complied DONT_OPTIMIZE and BETTER_BACKTRACES, but not DEBUG_THREADS nor MALLOC_DEBUG because of performance considerations. I hope the enclosed files will give you the information you requested.
As I said above, the crash came out of a 'clear blue sky', because we weren't carrying out any Stasis operations at the time (I can send you logs for our Stasis application if you wish, which tracks all outgoing commands and incoming notifications for the Asterisk box). We've been running with the same configuration for six months and haven't had a crash like this. It's not something we can reproduce (nor would we want to as this is a production system).
The nature of the unprovoked FRACK (unprovoked at least by our Stasis app) led me to suspect the jitterbuffer, and tracing through the code seems to confirm this, as the reference count is exceeded when the jitterbuffer code references the media type of the frame. We don't have a record of the specific codecs being used, but this is from our pjsip.conf:
allow = alaw
allow = ulaw
allow = gsm
> Frack (crash), excessive refcount during Jitterbuffer operation
> ---------------------------------------------------------------
>
> Key: ASTERISK-27617
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-27617
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/Jitterbuffer
> Affects Versions: 14.6.0
> Environment: Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-109-generic x86_64)
>
> Reporter: Colin
> Assignee: Unassigned
> Attachments: CoreDump-brief.txt, CoreDump-full.txt, CoreDump-thread1.txt, jitterbuffer frack.txt
>
>
> During an __ast_read operation on a pushed frame (in abstract_jb::hook_event_cb()), the reference count on the ast_frame_subclass resulted in a FRACK, and system crash.
> The referenced field which triggered the failed assert was out->subclass.format - a reference to the Asterisk media format. Bumping this causes the EXCESSIVE_REF_COUNT to be exceeded.
> This instance of Asterisk was participating in a Stasis application, with around 28 callers. At the time of the crash around 20 were muted, but no bridge or channel operations were being carried out by the Stasis application.
> Core dump included as text file.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list