6 Oct
2009
6 Oct
'09
12:03 p.m.
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
6 Oct
6 Oct
12:52 p.m.
On Oct 06, 2009 at 11:03, Henning Westerholt <henning.westerholt(a)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
1:49 p.m.
On Oct 06, 2009 at 11:52, Andrei Pelinescu-Onciul <andrei(a)iptel.org> wrote:
On Oct 06, 2009 at 11:03, Henning Westerholt
<henning.westerholt(a)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
2:37 p.m.
On Dienstag, 6. Oktober 2009, Andrei Pelinescu-Onciul wrote:
Thanks Andrei,
it not crashes anymore now.
Henning
> 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.
5529
days inactive
5529
days old
3 comments
2 participants
participants (2)
-
Andrei Pelinescu-Onciul -
Henning Westerholt