[Home]

Summary:ASTERISK-00845: [patch] you can unload chan_zap.so and reload from cli without segfault
Reporter:Brian West (bkw918)Labels:
Date Opened:2004-01-14 20:56:58.000-0600Date Closed:2004-09-25 02:55:01
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_zap_unload_reload.diff.txt
( 1) pri.txt
Description:This fixes chan_zap.  It had a few bugs that wouldn't let you unload and reload chan_zap without a seg_fault.  It apparently didn't unregister everything thus caused a seg fault.  Plus it set the iflist to NULL before we had a chance to destroy them.  I have attached a patch.  Please test.

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

If you change the signaling and the configured state of the zaptel interface is not in line with zapata.conf, it will not load chan_zap.so
Comments:By: Brian West (bkw918) 2004-01-14 21:06:32.000-0600

on a side note you can change signalling .. just make sure you run ztcfg before you try to load chan_zap.so
By: jrollyson (jrollyson) 2004-01-14 21:20:16.000-0600

Not quite working with PRI and T400P, or maybe I need to make clean first.

(gdb) bt full
#0  0x405f8d83 in ?? ()
No symbol table info available.
#1  0x400220ba in pthread_start_thread () from /lib/libpthread.so.0
No symbol table info available.
By: Brian West (bkw918) 2004-01-14 21:21:16.000-0600

It may be the monitor thread for the D channel not getting killed... but we are getting a few steps closer.
By: Brian West (bkw918) 2004-01-14 22:27:56.000-0600

asterisk*CLI> unload chan_zap.so
 == Manager unregistered action ZapDialOffhook
 == Manager unregistered action ZapHangup
 == Manager unregistered action ZapTransfer
 == Unregistered application 'CallingPres'
 == Unregistered channel type 'Tor'
 == Unregistered channel type 'Zap'
   -- Unregistered channel 1
   -- Unregistered channel 2
asterisk*CLI> load chan_zap.so
Loaded /usr/lib/asterisk/modules/chan_zap.so => (Zapata Telephony w/PRI)
 == Parsing '/etc/asterisk/zapata.conf':   == Parsing '/etc/asterisk/zapata.conf': Found
   -- Registered channel 1, FXS Kewlstart signalling
   -- Registered channel 2, FXS Kewlstart signalling
 == Registered channel type 'Zap' (Zapata Telephony Driver w/PRI)
 == Registered channel type 'Tor' (Zapata Telephony Driver w/PRI)
 == Registered application 'CallingPres'
 == Manager registered action ZapTransfer
 == Manager registered action ZapHangup
 == Manager registered action ZapDialOffhook
By: Brian West (bkw918) 2004-01-14 23:58:26.000-0600

Attached a fix for PRI users. :)
By: jrollyson (jrollyson) 2004-01-14 23:59:38.000-0600

Tested the PRI fixes, works flawlessly.
By: Brian West (bkw918) 2004-01-15 00:36:18.000-0600

This patch will not allow reload if you change zapata.conf since asterisk was started.  This will satisfy marks requirement that the signalling can't be changed between reloads on chan_zap.  It's a bad idea to do so(tm)
By: jjhuff (jjhuff) 2004-01-15 10:04:53.000-0600

Worked for me once I changed the condition in load_module() to
if((ast_startuptime > 0) && (zapata_conf.st_mtime > ast_startuptime)) {

ast_startuptime isn't set while * is loading modules.   What should that var *really* mean?  Should we move where it gets set?
By: zoa (zoa) 2004-01-15 13:42:40.000-0600

just a little remark:

how will this affect ongoing things that need a timing device like trunking or MOH?
By: Brian West (bkw918) 2004-01-15 13:45:55.000-0600

jjhuff we removed that check you can now even change the signalling on an unload and reload.
By: Brian West (bkw918) 2004-01-15 13:48:18.000-0600

zoa unload/load will not bother meetme, trunking nor moh
By: Tilghman Lesher (tilghman) 2004-01-15 14:00:39.000-0600

Uh, if malloc fails and returns NULL, you should not attempt to free() NULL.

@ -5129,6 +5130,7 @@
tmp = (struct zt_pvt*)malloc(sizeof(struct zt_pvt));
if (!tmp) {
ast_log(LOG_ERROR, "MALLOC FAILED\n");
+ free(tmp);
return NULL;
}
By: Brian West (bkw918) 2004-01-15 14:02:06.000-0600

Added to CVS
By: zoa (zoa) 2004-01-15 14:10:17.000-0600

tested, works fine, doest allow unloading calls when calls are in progress, so sweeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeet !


tested on TE410P with euroisdn.