22 May
2011
22 May
'11
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