22 May
2011
22 May
'11
4:13 a.m.
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
22 May
22 May
8:19 a.m.
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 -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
8:10 a.m.
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
11:27 a.m.
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:
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
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
4975
days inactive
4975
days old
3 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen