[Home]

Summary:ASTERISK-08047: asterisk segfaults at ast_translator_free_path ()
Reporter:Ivan Mitev (boris)Labels:
Date Opened:2006-11-02 05:04:41.000-0600Date Closed:2011-06-07 14:00:42
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bt_full_1
Description:after updating from 1.2.12.1 to 1.2.13, asterisk segfaults quickly

the full bt trace is in additional info

the machine it happens on is running centos 4.4, AMD Sempron(tm) 2800+, kernel 2.6.9-42.0.3.EL i686, and is running perfectly with 1.2.12.1

i don't have the knowledge to debug that more, but i can do some more tests if needed.
however since the machine is in production, it's quite a challenge to install asterisk's debug version, wait for the crash/core, and quickly reinstall the 1.12.1 version
moreover, i don't know what's in the core file (eg. passwords ?), so i'd prefer to send it by email instead of attaching it

****** ADDITIONAL INFORMATION ******

bt full with asterisk built with make valgrind:

#0  0x0806b280 in ast_translator_free_path (p=0x100) at translate.c:98
98      translate.c: No such file or directory.
       in translate.c
(gdb) bt full
#0  0x0806b280 in ast_translator_free_path (p=0x100) at translate.c:98
       pl = (struct ast_trans_pvt *) 0x100
       pn = (struct ast_trans_pvt *) 0x100
#1  0x0806296d in free_translation (clone=0x9dd76c8) at channel.c:1303
No locals.
#2  0x08062b06 in ast_hangup (chan=0x9dd76c8) at channel.c:1340
       res = 0
       __PRETTY_FUNCTION__ = "ast_hangup"
#3  0x0808b285 in __ast_pbx_run (c=0x9dd76c8) at pbx.c:2467
       firstpass = 1
       digit = 0
       exten = '\0' <repeats 255 times>
       pos = 0
       waittime = 0
       res = -1
       autoloopflag = 0
       __PRETTY_FUNCTION__ = "__ast_pbx_run"
#4  0x0808b3f4 in pbx_thread (data=0x9dd76c8) at pbx.c:2517
       c = (struct ast_channel *) 0x9dd76c8
ASTERISK-1  0x00a41371 in start_thread () from /lib/tls/libpthread.so.0
No symbol table info available.
ASTERISK-2  0x00959ffe in clone () from /lib/tls/libc.so.6
No symbol table info available.
Comments:By: Ivan Mitev (boris) 2006-11-02 05:16:55.000-0600

sorry i've pasted the backtrace instead of attaching it ; it's quit short though...
By: Anthony LaMantia (alamantia) 2006-11-03 12:06:48.000-0600

this is sort of difficult without some more debug infomration..
but it seems the problem is

ast_translator_free_path (p=0x100)

the address of p is croupt and not a valid memory address for ast_trans_pvt struct.

is there a way you can attach a btfull and a console debug log to this bugid so we can work on resolving this problem?

if you are really really unable to build the debug version

as root set your core size to this
ulimit -c unlimited    

wait for asterisk to core dump

open the dump

gcb -c ./core

type bt full and provide us with the output


By: Ivan Mitev (boris) 2006-11-03 13:07:03.000-0600

attached bt_full_1 ... (this time i've built a debuginfo rpm)

console debug: (call path: h323 phone -> asterisk box1 -> iax trunk -> asterisk box2 -> h323 gateway -> fxs analog phone)

   -- Accepting AUTHENTICATED call from m.n.o.p:
      > requested format = g729,
      > requested prefs = (g729),
      > actual format = g729,
      > host prefs = (g729),
      > priority = mine
   -- Executing Dial("IAX2/mitevbg_ast1-15", "OH323/1132@a.b.c.d|180") in new stack
   -- H.323 call to 1132@a.b.c.d with codec(s) g729
   -- Outbound H.323 call to destination '1132@a.b.c.d', channel 'OH323/1132@a.b.c.d-bda2592c'.
   -- Called 1132@a.b.c.d
srv-ast-sp1*CLI>
Disconnected from Asterisk server

it's late here in bulgaria, so i can do more tests if needed (on this week-end too)


By: Ivan Mitev (boris) 2006-11-04 05:55:22.000-0600

removing the oh323 channel "fixes" the problem...

since quite some time, i'm only updating asterisk without rebuilding the oh323 channel against the current devel files, and it has always worked fine.

today i've also put a voismart gsm pci card in production, and during my oh323 debugging tests, i saw that chan_vgsm compiled for 1.2.13 would crash on 1.2.12.1 while working on 1.2.13

it's either a coincidence, or something has changed in 1.2.13, that would need a recompile of out-of-tree channels against the new includes. or maybe it's always the case on upgrades, and i was lucky until now :)

however, while rebuilding chan_vgsm fixes the vgsm crashes, it doesn't help with chan_oh323 and asterisk still segfaults :(
since removing h323 support is not an option, and chan_h323 never worked for me, i've tried again with ooh323, with a hack to support receiveAndTransmitAudioCapability for our h323 gateways (i've already asked the ooh323 developpers about this some time ago and had found an ugly way to make it work, but since oh323 was ok, i didn't dare put in in production ; for those interested, see the answer to my mail from a ooh323 dev: http://www.mail-archive.com/ooh323c-devel@lists.sourceforge.net/msg00373.html )

now everything is working, so i think i'll stick with the ooh323 setup ; however if someone is interested in debugging the chan_oh323 sefgault, i'll be happy to help (but late in the evening !)


By: Serge Vecher (serge-v) 2006-11-09 10:42:41.000-0600

boris: chan_oh323 is known to be dysfunctional in 1.2 branch. Thanks to PCAdach's efforts, it is back and alive in 1.4 / trunk. Due to complexity, the changes that were done in 1.4 will not be backported to 1.2. If using a h323 channel driver is your priority, your options are: 1) Test 1.4-beta3 and see if it is stable enough for your needs, 2) continue using chan_ooh323 with 1.2 and see if the specific issues there are addressed, opening new bug reports in the process.

Also, chan_vgsm is not officially supported by Asterisk, so please do not discuss it's usage on the Asterisk bug-tracker.

I hope this gives you enough information to proceed. I'm closing this issue.