[Home]

Summary:ASTERISK-07795: 1.4.0b2 crashes on 'reload' if chan_skinny is loaded
Reporter:xrobau (xrobau)Labels:
Date Opened:2006-09-21 18:17:06Date Closed:2006-09-22 17:19:33
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_skinny
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Doing a 'reload' with a build of 1.4b2 causes a crash on CentOS 4.4 (at least). I've had two reports of it, and have duplicated it myself.

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

Nothing much in the backtrace, I'm afraid:

#0  0x0091dd34 in pthread_mutex_lock () from /lib/tls/libpthread.so.0
(gdb) bt full
#0  0x0091dd34 in pthread_mutex_lock () from /lib/tls/libpthread.so.0
No symbol table info available.
#1  0x080e402f in ast_sched_wait (con=0x0) at ../include/asterisk/lock.h:532
       ms = 9592820
#2  0x003086d3 in do_monitor (data=0x0) at chan_skinny.c:4241
       res = 33059872
#3  0x080efe15 in dummy_start (data=0x1f87420) at utils.c:538
       _buffer = {__routine = 0x80670c0 <ast_unregister_thread>, __arg = 0x1f87bb0, __canceltype = 0, __prev = 0x0}
       ret = Variable "ret" is not available.
(gdb)
Comments:By: xrobau (xrobau) 2006-09-21 20:10:00

I've just been told that this doesn't happen on Gentoo. I'll try it on Ubuntu later today.
By: xrobau (xrobau) 2006-09-21 20:29:24

file just mentioned on IRC that a noload of chan_skinny.so may stop it from crashing, and this is in fact the case.
By: xrobau (xrobau) 2006-09-21 20:39:40

BT with 'DONT_OPTIMIZE' set:

(gdb) bt full
#0  0x0091dd34 in pthread_mutex_lock () from /lib/tls/libpthread.so.0
No symbol table info available.
#1  0x080dc1fa in ast_mutex_lock (pmutex=0x0) at ../include/asterisk/lock.h:532
No locals.
#2  0x080dc2ef in ast_sched_wait (con=0x0) at sched.c:154
       ms = 155422856
#3  0x0044a035 in do_monitor (data=0x0) at chan_skinny.c:4241
       res = 155406096
#4  0x080e93f7 in dummy_start (data=0x9434f10) at utils.c:538
       _buffer = {__routine = 0x8067c15 <ast_unregister_thread>, __arg = 0x3debbb0, __canceltype = 0,
 __prev = 0x0}
       ret = (void *) 0x8a26f4
       a = {start_routine = 0x44a010 <do_monitor>, data = 0x0,
 name = 0x9411588 "do_monitor", ' ' <repeats 11 times>, "started at [ 4276] chan_skinny.c restart_monitor()"}
ASTERISK-1  0x0091c371 in start_thread () from /lib/tls/libpthread.so.0
No symbol table info available.
ASTERISK-2  0x00844ffe in clone () from /lib/tls/libc.so.6
No symbol table info available.
By: Jason Parker (jparker) 2006-09-21 22:13:25

I just committed something to branch/1.4 in svn that may (or may not..) fix this.  Could you give it a shot?  You'll have to checkout http://svn.digium.com/svn/asterisk/branch/1.4
By: xrobau (xrobau) 2006-09-21 23:51:19

wpm4l-gw*CLI> show version
Asterisk SVN-branch-1.4-r43469 built by root @ wpm4l-gw.wpm4l.com on a i686 running Linux on 2006-09-22 04:47:11 UTC
wpm4l-gw*CLI> reload
The 'reload' command is deprecated and will be removed in a future release. Please use 'module reload' instead.
wpm4l-gw*CLI>
Disconnected from Asterisk server
[root@wpm4l-gw asterisk]# /usr/sbin/safe_asterisk: line 42: 15602 Segmentation fault      (core dumped) ${ASTSBINDIR}/asterisk ${CLIARGS} ${ASTARGS} >&/dev/${TTY} </dev/${TTY}
By: jmls (jmls) 2006-09-22 04:46:46

I cannot reproduce this on the following: Centos 4.3 with all updates

Asterisk SVN-branch-1.4-r43469 built by root @ foxtrot on a i686 running Linux on 2006-09-22 09:44:10 UTC
By: Serge Vecher (serge-v) 2006-09-22 10:54:53

jmls: is chan_skinny loaded in your case?
xrobau: please upload a new backtrace from SVN-branch-1.4-r43469
By: jmls (jmls) 2006-09-22 11:09:33

list modules gives me (amongst other things!)

chan_skinny.so                 Skinny Client Control Protocol (Skinny)  0
By: Jason Parker (jparker) 2006-09-22 17:19:33

The latest versions of branch/1.4 (r43518) and trunk (r43519) no longer have reload support in chan_skinny (it was broken..obviously).  If you're still having problems, it's unrelated, and we need to find it.

Please test, and report back here if you're still getting a crash on reload.