[asterisk-bugs] [JIRA] (ASTERISK-22353) Random Asterisk Segmentation Fault

Mon Sep 16 18:09:03 CDT 2013

    [ https://issues.asterisk.org/jira/browse/ASTERISK-22353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210314#comment-210314 ] 

Freetech Solutions commented on ASTERISK-22353:
-----------------------------------------------

We were not able yet to reproduce the issue again after updating libopenr2 and installing debug symbol flags.
It had been running as expected during whole past week.

Seems to be that the update from 1.3.2 to 1.3.3 solved the problem.
We assume that if we do not have any new report we can close this item.

Current libraries running:
libopenr2-1.3.3-0
libopenr2-devel-1.3.3-0
libopenr2-debuginfo-1.3.3-0

Rgds,

> Random Asterisk Segmentation Fault
> ----------------------------------
>
>                 Key: ASTERISK-22353
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22353
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 1.8.23.0
>         Environment: CentOS release 5.7 (Final)
> Kernel 2.6.18-238.12.1.el5 #1 SMP Tue May 31 13:23:01 EDT 2011 i686 i686 i386 GNU/Linux
> Asterisk 1.8.23.0
> DAHDI Version: 2.6.1 Echo Canceller: HWEC, OSLEC
> libpri-1.4.14-0
> libpri-devel-1.4.14-0
> libopenr2-1.3.2-1
> libopenr2-devel-1.3.2-1
> Cards Installed: 03:08.0 Communication controller: Digium, Inc. Wildcard TE420 quad-span T1/E1/J1 card 3.3V (PCI-Express) (5th gen) (rev 02)
> Elastix 2.4 web framework
>            Reporter: Freetech Solutions
>            Assignee: Freetech Solutions
>         Attachments: backtrace.txt, full_21082013.gz, system.conf
>
>
> Randomly, asterisk is generating a coredump:
> -rw------- 1 asterisk asterisk  26M Feb 13  2013 core.conci-elx.example.com-2013-02-13T18:01:49-0300
> -rw------- 1 asterisk asterisk  539 Aug 20 19:41 core.conci-elx.example.com-2013-07-01T15:08:54-0300
> -rw------- 1 asterisk asterisk  48M Jul  2 11:50 core.conci-elx.example.com-2013-07-02T11:50:07-0300
> -rw------- 1 asterisk asterisk  58M Jul  8 18:35 core.conci-elx.example.com-2013-07-08T18:35:31-0300
> -rw------- 1 asterisk asterisk  99M Jul 15 17:15 core.conci-elx.example.com-2013-07-15T17:15:04-0300
> -rw------- 1 asterisk asterisk  86M Jul 18 12:23 core.conci-elx.example.com-2013-07-18T12:23:12-0300
> -rw------- 1 asterisk asterisk  90M Jul 22 19:30 core.conci-elx.example.com-2013-07-22T19:30:07-0300
> -rw------- 1 asterisk asterisk  43M Jul 23 11:23 core.conci-elx.example.com-2013-07-23T11:23:39-0300
> -rw------- 1 asterisk asterisk  87M Aug 13 17:15 core.conci-elx.example.com-2013-08-13T17:15:40-0300
> -rw------- 1 asterisk asterisk  544 Aug 20 19:13 core.conci-elx.example.com-2013-08-20T17:15:44-0300
> GDB output belongs to file "core.conci-elx.example.com-2013-08-21T11:08:39-0300".
>  
> Full log at the moment of the coredump shows nothing abnormal:
> [Aug 21 11:08:31] VERBOSE[4439] res_agi.c:     -- <DAHDI/9-1>AGI Script hangup.agi completed, returning 0
> [Aug 21 11:08:31] VERBOSE[4439] pbx.c:     -- Executing [s at macro-hangupcall:51] Hangup("DAHDI/9-1", "") in new stack
> [Aug 21 11:08:31] VERBOSE[4439] app_macro.c:   == Spawn extension (macro-hangupcall, s, 51) exited non-zero on 'DAHDI/9-1' in macro 'hangupcall'
> [Aug 21 11:08:31] VERBOSE[4439] features.c:   == Spawn extension (ext-queues, h, 1) exited non-zero on 'DAHDI/9-1'
> [Aug 21 11:08:32] VERBOSE[4851] pbx.c:     -- Executing [s at ivr-3:9] Set("DAHDI/24-1", "TIMEOUT(digit)=3") in new stack
> [Aug 21 11:08:32] VERBOSE[4851] func_timeout.c:     -- Digit timeout set to 3.000
> [Aug 21 11:08:32] VERBOSE[4851] pbx.c:     -- Executing [s at ivr-3:10] Set("DAHDI/24-1", "TIMEOUT(response)=3") in new stack
> [Aug 21 11:08:32] VERBOSE[4851] func_timeout.c:     -- Response timeout set to 3.000
> [Aug 21 11:08:32] VERBOSE[4851] pbx.c:     -- Executing [s at ivr-3:11] Set("DAHDI/24-1", "__IVR_RETVM=") in new stack
> [Aug 21 11:08:32] VERBOSE[4851] pbx.c:     -- Executing [s at ivr-3:12] ExecIf("DAHDI/24-1", "1?Background(en/cc_01_central)") in new stack
> [Aug 21 11:08:32] VERBOSE[4851] file.c:     -- <DAHDI/24-1> Playing 'en/cc_01_central.alaw' (language 'en')
> [Aug 21 11:08:39] VERBOSE[4439] res_musiconhold.c:     -- Started music on hold, class 'freetech', on SIP/2003-00000000
> [Aug 21 11:08:39] VERBOSE[4439] pbx.c:   == Spawn extension (ext-queues, 7005, 10) exited non-zero on 'DAHDI/9-1'
> [Aug 21 11:08:39] DEBUG[4439] chan_dahdi.c: disconnecting MFC/R2 call on chan 9
> [Aug 21 11:08:39] DEBUG[4439] chan_dahdi.c: ast cause 16 resulted in openr2 cause 6/Normal Clearing
> [Aug 21 11:08:39] DEBUG[1169] chan_dahdi.c: Chan 9 - Bits changed from 0x00 to 0x08
> [Aug 21 11:08:39] DEBUG[1169] chan_dahdi.c: Chan 9 - CAS Rx << [CLEAR FORWARD] 0x08
> [Aug 21 11:08:39] DEBUG[1169] chan_dahdi.c: Chan 9 - Call ended
> [Aug 21 11:08:39] DEBUG[1169] chan_dahdi.c: Chan 9 - CAS Tx >> [IDLE] 0x08
> [Aug 21 11:08:39] DEBUG[1169] chan_dahdi.c: Chan 9 - CAS Raw Tx >> 0x09
> [Aug 21 11:08:39] VERBOSE[1169] chan_dahdi.c: MFC/R2 call end on channel 9
> This crash disconnects all current calls and causes logoff for all dinamic agents involved.
> Attached the gdb backtrace.txt with "thread apply all bt" activated, also system.conf dahdi configuration example.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira