Summary:ASTERISK-14244: Realtime IAX2 crash
Reporter:Mindaugas Kezys (mkezys)Labels:
Date Opened:2009-06-01 08:10:01Date Closed:2011-06-07 14:00:49
Versions:Frequency of
Environment:Attachments:( 0) gdb_output.txt
( 1) last_cli_lines_before_crash.txt
Description:Asterisk crashes when realtime engine tries update device info in DB.


CentOS release 5 (Final)

iax.conf related part:


gdb and cli before crash outputs are attached
Comments:By: Leif Madsen (lmadsen) 2009-06-01 14:09:37

I'm not entirely sure why this is marked as a crash in res_config_mysql -- can you elaborate?

By: Mindaugas Kezys (mkezys) 2009-06-01 15:43:45

That was my best guess. Maybe it is related to chan_iax2.c based on:

#0  0x0000000000413059 in ast_free_ha (ha=0x2f0) at acl.c:258
#1  0x00002aaab915e7ef in peer_destructor (obj=0x2aaab0100668) at chan_iax2.c:9554
#2  0x000000000042e551 in ao2_ref (user_data=0x2aaab0100668, delta=-1) at astobj2.c:229
#3  0x00002aaab912fc2a in peer_unref (peer=0x2aaab0100668) at chan_iax2.c:1191
#4  0x00002aaab914c482 in __iax2_poke_peer_s (data=0x2aaab0100668) at chan_iax2.c:6719
ASTERISK-1  0x00002aaab915af91 in iax2_process_thread (data=0x2aaab0074ea0) at chan_iax2.c:8881
ASTERISK-2  0x00000000004e0f55 in dummy_start (data=0x2aaab0071140) at utils.c:856
ASTERISK-3  0x0000003ab26062f7 in start_thread () from /lib64/libpthread.so.0
ASTERISK-4  0x0000003ab16ce85d in clone () from /lib64/libc.so.6

I do not know Asterisk internals very well. I guess it is 10s job for you to change Category of this ticket to reflect situation more clearly.

By: Leif Madsen (lmadsen) 2009-06-09 08:14:23

Ya, I'm not too sure either -- I was just hoping you had good reason why it was marked there, or rather, why it wasn't marked as chan_iax2. We'll leave it as-is for now. Thanks!

By: Leif Madsen (lmadsen) 2009-06-10 11:59:23

Assigned to Mr. Vossel in the hopes he can take this issue to the next step. Thanks!

By: David Vossel (dvossel) 2009-07-15 12:19:52

I've looked into the bt and based upon what I'm seeing I don't have a solution.  Is this a consistent crash you are seeing?  If so try taking out rtautoclear and see if that helps.

By: Mindaugas Kezys (mkezys) 2009-07-17 01:20:26

It was on my clients' production server. As we get bored of these crashes, we are restarting Asterisk every midnight, it "solves" this problem - no more coredumps from that time.

As we will redesign our system to do not use broken ARA at all, I think this issue will not be important for us any longer.

Thank you for looking into this issue after 45 days...

By: David Vossel (dvossel) 2009-07-18 00:29:51

Sorry it took so long to get to the issue.  If you're still willing to provide information about the bug I'll continue to investigate it as I have time.  If not, I'll close it.  Let me know.

By: David Vossel (dvossel) 2009-07-24 13:12:30

feel free to reopen if you are willing to pursue this any further.