| Summary: | ASTERISK-22688: chan_sip: send_provisional_keepalive_full called on destroyed SIP pvt resulting in crash | ||
| Reporter: | Kingsley Tart (skycomltd) | Labels: | |
| Date Opened: | 2013-10-14 10:22:54 | Date Closed: | 2017-12-18 11:43:36.000-0600 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | 11.2.0 | Frequency of Occurrence | One Time |
| Related Issues: | |||
| Environment: | Centos 6.4 64bit Asterisk 11.2-cert2 glibc-2.12-1.107.el6_4.2.x86_64 | Attachments: | ( 0) core_backtrace.txt |
| Description: | Server has been up for 50 days and regularly handles 60 concurrent calls (we have other busier servers). Today we had a core dump.
In the asterisk logs :- [Oct 14 15:55:53] ERROR[1650] astobj2.c: bad magic number for 0x7fb67452dad8. Object is likely destroyed. Kernel messages :- Oct 14 15:55:53 gw3 kernel: asterisk[1650]: segfault at 18 ip 00000034f1f3b8ff sp 00007fb679908088 error 4 in libc-2.12.so[34f1e00000+18a000] Oct 14 15:56:00 gw3 abrt[7599]: Saved core dump of pid 1630 (/usr/sbin/asterisk) to /var/spool/abrt/ccpp-2013-10-14-15:55:53-1630 (171835392 bytes) I see that there is a newer glibc 2.12-1.107.el6_4.4 available. Please could you advise if its an asterisk issue or definitely a fault with glibc. I will upload the core dump shortly. | ||
| Comments: | By: Kingsley Tart (skycomltd) 2013-10-14 10:24:36.893-0500 crash core dump By: Matt Jordan (mjordan) 2013-10-14 10:37:10.045-0500 We'll need the backtrace from the core dump to know for sure, which has to be done on the machine that generated the core dump. You can extract the backtrace using the instructions on the wiki: https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace By: Kingsley Tart (skycomltd) 2013-10-14 10:51:03.620-0500 Core dump backtrace By: Kingsley Tart (skycomltd) 2013-10-14 11:19:19.894-0500 Backtrace has been added By: Rusty Newton (rnewton) 2013-10-25 18:17:48.758-0500 Gareth was Asterisk built without optimizations? I'm assuming it was built with optimizations since it sounds like it was a unreproducible crash on a production system. By: Kingsley Tart (skycomltd) 2013-10-25 18:39:19.047-0500 I don't have access to the server at the moment but it was compiled from source with no changes made to the compiler settings so it will be whatever 'make menuselect' has at default. By: Richard Mudgett (rmudgett) 2013-10-25 20:02:19.280-0500 The default is to do an optimized build which is what the backtrace is showing. By: Joshua C. Colp (jcolp) 2017-12-18 11:28:31.230-0600 Has this happened again recently on a supported version of Asterisk? By: Kingsley Tart (skycomltd) 2017-12-18 11:33:05.425-0600 This is a very old report. We have been running a later version not for a considerable amount of time without issue. | ||