[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