i had forgotten to define an m4 macro and had in config
if (isflagset(AUTHORIZED) || ...
that causes sr to crash at startup:
May 22 11:07:14 sip kernel: [106986.110502] sip-proxy[12858]: segfault at 4 ip b66cce71 sp bfca9bb0 error 4 in htable.so[b66c6000+f000] Not starting sip-proxy: invalid configuration file!
0(12858) INFO: pv [pv_shv.c:61]: locks array size 16 0(12858) : <core> [cfg.y:3440]: parse error in config file /etc/sip-proxy/sip-proxy.cfg, line 3837, column 37: flag not declared ERROR: bad config file (1 errors)
i think i have earlier reported same kind of crash in another situation. this is using master version. why does sr crash in htable.so module that has nothing to do with this flag?
-- juha
Hello,
On 5/22/11 10:13 AM, Juha Heinanen wrote:
i had forgotten to define an m4 macro and had in config
if (isflagset(AUTHORIZED) || ...that causes sr to crash at startup:
May 22 11:07:14 sip kernel: [106986.110502] sip-proxy[12858]: segfault at 4 ip b66cce71 sp bfca9bb0 error 4 in htable.so[b66c6000+f000] Not starting sip-proxy: invalid configuration file!
0(12858) INFO: pv [pv_shv.c:61]: locks array size 16 0(12858) :<core> [cfg.y:3440]: parse error in config file /etc/sip-proxy/sip-proxy.cfg, line 3837, column 37: flag not declared ERROR: bad config file (1 errors)
i think i have earlier reported same kind of crash in another situation. this is using master version. why does sr crash in htable.so module that has nothing to do with this flag?
it could be due to latest enhacements of htable module to sync back to db the content in memory at shutdown - inside destroy() module function - in this case maybe the structures are not initialized and safety checked. Can you get the backtrace?
Cheers, Daniel
Daniel-Constantin Mierla writes:
it could be due to latest enhacements of htable module to sync back to db the content in memory at shutdown - inside destroy() module function
- in this case maybe the structures are not initialized and safety
checked. Can you get the backtrace?
(gdb) where #0 0xb66cce71 in ht_destroy () at ht_api.c:326 #1 0xb66c90bd in destroy () at htable.c:231 #2 0x080efb84 in destroy_modules () at sr_module.c:732 #3 0x0809000c in cleanup (show_status=0) at main.c:530 #4 0x08090c99 in shutdown_children (show_status=0, sig=<value optimized out>) at main.c:672 #5 0x080937c7 in main (argc=18, argv=0xbfca9dd4) at main.c:2452
-- juha
Should be fixed now. I changed how the module was initialized in the last commits in master (avoiding usage of private memory for temporary operations), causing this when there were other errors during startup before module initialization happened.
Thanks, Daniel
On 5/22/11 2:10 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
it could be due to latest enhacements of htable module to sync back to db the content in memory at shutdown - inside destroy() module function
- in this case maybe the structures are not initialized and safety
checked. Can you get the backtrace?
(gdb) where #0 0xb66cce71 in ht_destroy () at ht_api.c:326 #1 0xb66c90bd in destroy () at htable.c:231 #2 0x080efb84 in destroy_modules () at sr_module.c:732 #3 0x0809000c in cleanup (show_status=0) at main.c:530 #4 0x08090c99 in shutdown_children (show_status=0, sig=<value optimized out>) at main.c:672 #5 0x080937c7 in main (argc=18, argv=0xbfca9dd4) at main.c:2452
-- juha
-
Daniel-Constantin Mierla -
Juha Heinanen