Summary: | ASTERISK-13322: Crash after - Remote peer reported an error, trying to establish the call anyway | ||
Reporter: | Visu Kaka (visu) | Labels: | |
Date Opened: | 2009-01-07 22:39:07.000-0600 | Date Closed: | 2011-06-07 14:08:26 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_gtalk |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | Asterisk always crashes after chan_gtalk.c: Remote peer reported an error, trying to establish the call anyway Visu | ||
Comments: | By: phsultan (phsultan) 2009-01-09 04:21:49.000-0600 Can you please elaborate on the crash. Which client (GoogleTalk, Gmail plugin, Telepathy) and version do you use? Any debug messages or stack trace available? By: Visu Kaka (visu) 2009-01-11 22:50:49.000-0600 After "Remote peer reported an error, trying to establish the call anyway", asterisk crashes without any messages. There are many users so would not know about client they use, but if you let me know how to get that info, I will be happy to trace it out Thx By: phsultan (phsultan) 2009-01-15 11:39:29.000-0600 First launch Asterisk with option -g in order to get a core file when Asterisk crashes, ex : #asterisk -vvvvg When Asterisk happen to crash, a core file is dumped under /tmp, with a name like /tmp/core.XXXXX. If multiple files are present, beware to point to the correct file in the next step. Open the core file with gdb : #gdb asterisk /tmp/core.XXXXX Store the output of the following command (under gdb) : bt full Attach the corresponding file to this ticket, do not post it as a note please. You'll have more information about how to get a backtrace in the doc/backtrace.txt file. By: phsultan (phsultan) 2009-02-12 08:34:50.000-0600 Did you have any chance to get a trace? That would help a lot, thanks! By: phsultan (phsultan) 2009-04-22 03:22:12 I'm suspending this bug report now. Please reopen when you get a stack trace analysis. By: Visu Kaka (visu) 2009-06-24 04:58:09 sorry for the delay. Below is backtrace and exact location of the crash. (please ignore chan_gtalk.c line numbers in bt since I added some logs the file). /* codec points to the first <payload-type/> tag */ codec = iks_first_tag(iks_first_tag(iks_first_tag(pak->x))); while (codec) { crash ==> ast_rtp_codecs_payloads_set_m_type(ast_rtp_instance_get_codecs(tmp->rtp), tmp->rtp, atoi(iks_find_attrib(codec, "id"))); ast_rtp_codecs_payloads_set_rtpmap_type(ast_rtp_instance_get_codecs(tmp->rtp), tmp->rtp, atoi(iks_find_attrib(codec, "id")), "audio", iks_find_attrib(codec, "name"), 0); codec = iks_next_tag(codec); } #0 0x00f0165a in gtalk_parser (data=0x8ce64a0, pak=0x9934740) at chan_gtalk.c:625 #1 0x001268c9 in iks_filter_packet (f=0xb7c137a0, pak=0x9934740) at filter.c:154 #2 0x00d2949c in aji_act_hook (data=0xb7c14a10, type=1, node=0x9969b24) at res_jabber.c:1042 #3 0x00124ab6 in tagHook (data=0xb7c13664, name=0x8d13bf0 "iq", atts=0x0, type=1) at stream.c:314 #4 0x00122d4f in iks_parse (prs=0xb7c136a4, data=0xc36296 "<iq to=\"visugtalk@gmail.com/visuE274B06E\" type=\"set\" id=\"19\" from=\"testaccxxx@gmail.com/Talk.v66310DF9CE\"><session type=\"accept\" id=\"610\" initiator=\"visugtalk@gmail.com/visuE274B06E\" xml"..., len=357, finish=0) at sax.c:324 ASTERISK-1 0x00d27fbf in aji_recv (client=0xb7c14a10, timeout=1) at res_jabber.c:686 ASTERISK-2 0x00d28dce in aji_recv_loop (data=0xb7c14a10) at res_jabber.c:1976 ASTERISK-3 0x0813fa1b in dummy_start (data=0xb7c084a0) at utils.c:1024 ASTERISK-4 0x0070245b in start_thread () from /lib/libpthread.so.0 ASTERISK-5 0x00659e5e in lseek64 () from /lib/libc.so.6 |