Hi all,
i get now a segfault in cfg_update[_local] for kamailio modules during my tests. It doesn't matter if the server start successfully, it even crashs when the server stops the start during some cfg file problems.
I remember that Miklos changes in the last week something in the cfg framework, perhaps its related to this? The cfg in question does nothing special, it just try to loads a bunch of kamailio modules, but as i said, it crashes for every configuration i've tried so far.
Backtrace:
Core was generated by `../../ser -w . -f 2.cfg'. Program terminated with signal 11, Segmentation fault. [New process 16270] #0 cfg_update_local () at cfg/cfg_struct.h:255 255 cfg_child_cb = cfg_child_cb->next; (gdb) bt #0 cfg_update_local () at cfg/cfg_struct.h:255 #1 0x0809c050 in sig_usr (signo=15) at main.c:782 #2 <signal handler called> #3 0xb7fd742e in __kernel_vsyscall () #4 0xb7f11e03 in __read_nocancel () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7ea8f4e in _IO_new_file_underflow (fp=0x98e98e0) at fileops.c:598 #6 0xb7eaacab in _IO_default_uflow (fp=0x98e98e0) at genops.c:440 #7 0xb7eac262 in *__GI___uflow (fp=0x98e98e0) at genops.c:394 #8 0xb7e9ea36 in _IO_getline_info (fp=0x98e98e0, buf=0x82b40b4 "�\003", n=1023, delim=10, extract_delim=1, eof=0x0) at iogetline.c:74 #9 0xb7e9e981 in _IO_getline (fp=0x98e98e0, buf=0x82b40b4 "�\003", n=1023, delim=10, extract_delim=1) at iogetline.c:42 #10 0xb7e9d86a in _IO_fgets (buf=0x82b40b4 "�\003", n=1024, fp=0x98e98e0) at iofgets.c:58 #11 0xb7c4769f in mi_read_line (b=0x82b40b4 "�\003", max=1024, stream=0x98e98e0, read=0xbfef22f8) at /usr/include/bits/stdio2.h:255 #12 0xb7c48957 in mi_fifo_server (fifo_stream=0x98e98e0) at fifo_fnc.c:415 #13 0xb7c4ad48 in fifo_process (rank=1) at mi_fifo.c:235 #14 0xb7c4afbd in mi_child_init (rank=0) at mi_fifo.c:199 #15 0x081099e7 in init_mod_child (m=0x82ac28c, rank=0) at sr_module.c:808 #16 0x08109970 in init_mod_child (m=0x82ac3dc, rank=0) at sr_module.c:785 #17 0x08109970 in init_mod_child (m=0x82ac528, rank=0) at sr_module.c:785 #18 0x08109970 in init_mod_child (m=0x82ac680, rank=0) at sr_module.c:785 #19 0x08109970 in init_mod_child (m=0x82ac7c8, rank=0) at sr_module.c:785 #20 0x08109970 in init_mod_child (m=0x82ac910, rank=0) at sr_module.c:785 #21 0x08109970 in init_mod_child (m=0x82aca68, rank=0) at sr_module.c:785 #22 0x08109970 in init_mod_child (m=0x82acbac, rank=0) at sr_module.c:785 #23 0x08109970 in init_mod_child (m=0x82acd00, rank=0) at sr_module.c:785 #24 0x08109970 in init_mod_child (m=0x82ace44, rank=0) at sr_module.c:785 #25 0x08109970 in init_mod_child (m=0x82acf88, rank=0) at sr_module.c:785 #26 0x08109970 in init_mod_child (m=0x82ad0e0, rank=0) at sr_module.c:785 #27 0x08109970 in init_mod_child (m=0x82ad2dc, rank=0) at sr_module.c:785 #28 0x08109970 in init_mod_child (m=0x82ad3d0, rank=0) at sr_module.c:785 #29 0x08109970 in init_mod_child (m=0x82ad570, rank=0) at sr_module.c:785 #30 0x08109970 in init_mod_child (m=0x82ad6c0, rank=0) at sr_module.c:785 #31 0x08109970 in init_mod_child (m=0x82ad810, rank=0) at sr_module.c:785 #32 0x08109970 in init_mod_child (m=0x82ad974, rank=0) at sr_module.c:785 #33 0x08109970 in init_mod_child (m=0x82adb28, rank=0) at sr_module.c:785 #34 0x08109970 in init_mod_child (m=0x82adc84, rank=0) at sr_module.c:785 #35 0x08109970 in init_mod_child (m=0x82adf6c, rank=0) at sr_module.c:785 #36 0x08109970 in init_mod_child (m=0x82b0564, rank=0) at sr_module.c:785 #37 0x08109970 in init_mod_child (m=0x82b0658, rank=0) at sr_module.c:785 #38 0x08109970 in init_mod_child (m=0x82b07fc, rank=0) at sr_module.c:785 #39 0x08109970 in init_mod_child (m=0x82b2398, rank=0) at sr_module.c:785 #40 0x0809b6bd in main_loop () at main.c:1504 #41 0x0809e10d in main (argc=5, argv=0xbfef2bf4) at main.c:2228 (gdb) p cfg_child_cb $1 = (cfg_child_cb_t *) 0x0 (gdb) l 250 if (unlikely(cfg_child_cb==CFG_NO_CHILD_CBS)) 251 return; 252 /* call the per-process callbacks */ 253 while (cfg_child_cb != last_cb) { 254 prev_cb = cfg_child_cb; 255 cfg_child_cb = cfg_child_cb->next; 256 atomic_inc(&cfg_child_cb->refcnt); 257 if (atomic_dec_and_test(&prev_cb->refcnt)) { 258 /* No more pocess refers to this callback. 259 Did this process block the deletion,
Regards,
Henning
On Oct 06, 2009 at 11:03, Henning Westerholt henning.westerholt@1und1.de wrote:
Hi all,
i get now a segfault in cfg_update[_local] for kamailio modules during my tests. It doesn't matter if the server start successfully, it even crashs when the server stops the start during some cfg file problems.
I remember that Miklos changes in the last week something in the cfg framework, perhaps its related to this?
It's my patch so I'm responsible :-) It is related to it. The 0 pointer crash is intentional and it should signal that someone uses cfg_update() on a process not registered for config framework use. Unfortunately my patch added a cfg_update() on process exit (to make sure they have the latest update values of the debug, memlog and memdebug) and I failed to account for kamailio modules that fork processes.
So I'll either disable the 0-crash (which has the disadvantage that in the future one might try to use the cfg. framework without proper intialization and it would seem to work at least for some of the vars => difficult debugging), remove the cfg_update() on exit (no memlog, debug update in some cases) or come up with something else. Another alternative would be to update all the k modules, but I want to avoid it since they don't use the cfg framework yet and it would introduce a lot of extra testing before a release.
Andrei
On Oct 06, 2009 at 11:52, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Oct 06, 2009 at 11:03, Henning Westerholt henning.westerholt@1und1.de wrote:
Hi all,
i get now a segfault in cfg_update[_local] for kamailio modules during my tests. It doesn't matter if the server start successfully, it even crashs when the server stops the start during some cfg file problems.
I remember that Miklos changes in the last week something in the cfg framework, perhaps its related to this?
Should be fixed now (at least the config changes are still seen on exit by all the processes and mi_fifo does not crash).
It's my patch so I'm responsible :-) It is related to it. The 0 pointer crash is intentional and it should signal that someone uses cfg_update() on a process not registered for config framework use. Unfortunately my patch added a cfg_update() on process exit (to make sure they have the latest update values of the debug, memlog and memdebug) and I failed to account for kamailio modules that fork processes.
So I'll either disable the 0-crash (which has the disadvantage that in the future one might try to use the cfg. framework without proper intialization and it would seem to work at least for some of the vars => difficult debugging), remove the cfg_update() on exit (no memlog, debug update in some cases) or come up with something else. Another alternative would be to update all the k modules, but I want to avoid it since they don't use the cfg framework yet and it would introduce a lot of extra testing before a release.
In the end, I just added a special update call, that is used only on process exit, before dumping memory debugging info.
Andrei
On Dienstag, 6. Oktober 2009, Andrei Pelinescu-Onciul wrote:
I remember that Miklos changes in the last week something in the cfg framework, perhaps its related to this?
Should be fixed now (at least the config changes are still seen on exit by all the processes and mi_fifo does not crash).
It's my patch so I'm responsible :-) It is related to it. The 0 pointer crash is intentional and it should signal that someone uses cfg_update() on a process not registered for config framework use. Unfortunately my patch added a cfg_update() on process exit (to make sure they have the latest update values of the debug, memlog and memdebug) and I failed to account for kamailio modules that fork processes.
So I'll either disable the 0-crash (which has the disadvantage that in the future one might try to use the cfg. framework without proper intialization and it would seem to work at least for some of the vars => difficult debugging), remove the cfg_update() on exit (no memlog, debug update in some cases) or come up with something else. Another alternative would be to update all the k modules, but I want to avoid it since they don't use the cfg framework yet and it would introduce a lot of extra testing before a release.
In the end, I just added a special update call, that is used only on process exit, before dumping memory debugging info.
Thanks Andrei,
it not crashes anymore now.
Henning
-
Andrei Pelinescu-Onciul -
Henning Westerholt