[asterisk-dev] Fixed: Reloading chan_unicall unloads res_odbc
Adolfo R. Brandes
arbrandes at instant.com.br
Fri Jun 9 13:28:09 MST 2006
This is for users of Steve Underwood's chan_unicall (and Steve himself).
I found a weird bug when using chan_unicall and res_odbc together,
where issuing a:
CLI> reload
Would cause res_odbc to be unloaded during chan_unicall's reload
procedure (not by coincidence, it turns out).
I was able to duplicate this in several boxes, running on anything
from Red Hat 7.2 and Fedora Core 4, from asterisk-1.2.4 to
asterisk-1.2.9.1, and various versions of unixODBC and libmyodbc.
It was always the same chan_unicall.c, however. Namely:
http://www.soft-switch.org/downloads/unicall/unicall-0.0.3pre9/libunicall-0.0.3.tar.gz
(dated 13-Aug-2005 09:51).
To make a long story short, this version of chan_unicall.c does not
declare and call the static __unload_module(), as I'm guessing it
should. So I went ahead and hacked it a bit, based on what I found
here:
http://lists.digium.com/pipermail/svn-commits/2003-December/000610.html
Make, make install, and voi la! No more reload problems.
I attached the patch for review. Not much to it:
* substituting calls to unload_module() for __unload_module()
* renaming "int unload_module()" to "static int __unload_module()"
* moving __unload_module up the code a bit, for the sake of the compiler
* creating the "int unload_module()" dummy
Cheers,
Adolfo R. Brandes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chan_unicall.diff
Type: application/octet-stream
Size: 5812 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20060609/d109e10b/chan_unicall.obj
More information about the asterisk-dev
mailing list