[Home]

Summary:ASTERISK-08650: * segfault on module unload chan_sip.so
Reporter:Clod Patry (junky)Labels:
Date Opened:2007-01-23 09:43:39.000-0600Date Closed:2007-01-23 17:00:35.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) unload_sip.txt
Description:When having active channels, if you unload chan_sip.so, that will make a segfault.


*CLI> core show channels
Channel              Location             State   Application(Data)            
SIP/202-08294f30     (None)               Up      Bridged Call(SIP/201-08290218)
SIP/201-08290218     202@gondor:1         Up      Dial(SIP/202)                
2 active channels
1 active call
*CLI> module unload chan_sip.so
 == Unregistered channel type 'SIP'
 == Unregistered custom function SIPCHANINFO
 == Unregistered custom function SIPPEER
 == Unregistered custom function SIP_HEADER
 == Unregistered custom function CHECKSIPDOMAIN
 == Unregistered application 'SIPDtmfMode'
 == Unregistered application 'SIPAddHeader'
 == Manager unregistered action SIPpeers
 == Manager unregistered action SIPshowpeer
Really destroying SIP dialog '41c98f7c500a0d247bc2674e4ab33c28@207.134.65.22' Method: INVITE
Really destroying SIP dialog 'b07c55f28c868bc998665e847655e8cc@10.22.0.1' Method: ACK
Really destroying SIP dialog '6271d8ed4abd4f618aeb008365ea4989@10.22.0.1' Method: REGISTER
Really destroying SIP dialog 'f5d3df68e0ad7e6946b591c43c96569b@10.22.0.1' Method: REGISTER
Really destroying SIP dialog '75952500eb44eeedbb34b9907ca0af8d@10.22.0.1' Method: REGISTER
Really destroying SIP dialog 'ee12439754c3646ec304d9de16e99c62@10.22.0.1' Method: REGISTER
*CLI> Segmentation fault (core dumped)
[cpatry@chouffe ~ (Mitos 1.1)]$
Comments:By: Olle Johansson (oej) 2007-01-23 09:47:38.000-0600

Why on earth do you unload chan_sip if you have active calls :-)
By: Clod Patry (junky) 2007-01-23 09:50:00.000-0600

Cause im testing it with some unit testing.

I had external script testing it and report me that bug, so i just filled a bug.

That should be managed by usecount and avoid the unload if an active calls for that module is active.
That test was running on 1.2.X fine, but not on 1.4.0.

I also tried:
*CLI> module unload app_dial.so
[Jan 23 10:53:35] WARNING[5916]: loader.c:453 ast_unload_resource: Soft unload failed, 'app_dial.so' has use count 1
Unable to unload resource app_dial.so

which is great.


By: Olle Johansson (oej) 2007-01-23 10:41:32.000-0600

Hmm. Can you please check version? The line number doesn't match. THanks.
By: Olle Johansson (oej) 2007-01-23 10:43:43.000-0600

Interesting, we just disconnect from the calls, but don't issue a hangup. Maybe we should issue a hangup... I don't know if the rest of Asterisk is prepared to handle calls without a tech_pvt...
By: Olle Johansson (oej) 2007-01-23 10:44:39.000-0600

Ok. chan_iax2 actually hangs up. Let's do that.
By: Clod Patry (junky) 2007-01-23 11:15:41.000-0600

my feel is we just block the unload and dont unload the module, except if we force it.
By: Joshua C. Colp (jcolp) 2007-01-23 17:00:35.000-0600

Fixed in 1.4 as of revision 51788 and trunk as of revision 51801 by updating things to use module reference use counts.