Hello,
I moved the initialization of internal buffer in srdb1 from mod_init of
each database module to mod_register() function -- this is a function
executed when a module is loaded.
Can you give it a try and see if works fine now even with modules needed
DB loaded before the database connector module? If all is reported ok,
then I will backport.
Thanks,
Daniel
On 10/30/11 5:03 PM, Peter Dunkley wrote:
Hi,
I will pass this along to Andy Miller who implemented this change. I
don't know when he will have time to look into this.
Regards,
Peter
On Sun, 2011-10-30 at 18:01 +0200, Timo Teräs wrote:
Hi,
I just upgraded to kam 3.2.0 and my config started crashed. I did some
bisecting, until I came to commit 5cd87175faa97161023c37e2cc0f0c06
(core, srdb1, modules/db_*, modules_k/db_*: Added support for
configuring SQL buffer size and mediumblob/mediumtext in MySQL) which
seems to be the culprit.
It seems that this commit broke things that were earlier possible. My
existing configuration loads 'permissions' module before the
'db_postgres' module. This used to work perfectly well: the SQL modules
were usable after loading without requiring initialization.
After this commit, this causes segmentation fault with following backtrace:
#0 0xb7fabeaf in memcpy () from /lib/libc.so.0.9.32
#1 0xb7fa5b78 in ?? () from /lib/libc.so.0.9.32
#2 0xb7fa7148 in ?? () from /lib/libc.so.0.9.32
#3 0xb7fa4b16 in vsnprintf () from /lib/libc.so.0.9.32
#4 0xb7fa4862 in snprintf () from /lib/libc.so.0.9.32
#5 0xb5a7a540 in db_do_query (_h=0xb7c4553c, _k=0xbffff614, _op=0x0,
_v=0xbffff600, _c=0xbffff618, _n=1, _nc=1, _o=0x0, _r=0xbffff5fc,
val2str=0xb56ef1c0<db_postgres_val2str>, submit_query=0xb56f4a70
<db_postgres_submit_query>,
store_result=0xb56f5350<db_postgres_store_result>) at db_query.c:63
#6 0xb56f6a15 in db_postgres_query (_h=0xb7c4553c, _k=0xbffff614, _op=0x0,
_v=0xbffff600, _c=0xbffff618, _n=1, _nc=1, _o=0x0,
_r=0xbffff5fc) at km_dbase.c:370
#7 0xb5a7fdc9 in db_table_version (dbf=0xb5930be0,
connection=0xb7c4553c, table=0xb59303f0) at db.c:378
#8 0xb5a8044a in db_check_table_version (dbf=0xb5930be0,
dbh=0xb7c4553c, table=0xb59303f0, version=4) at db.c:416
#9 0xb591c6fe in init_addresses () at address.c:208
#10 0xb592238d in mod_init () at permissions.c:630
#11 0x001606d6 in init_mod (m=0xb7bc17f0) at sr_module.c:886
#12 0x0016064e in init_mod (m=0xb7bc1dc8) at sr_module.c:883
#13 0x0016064e in init_mod (m=0xb7bc23a8) at sr_module.c:883
#14 0x0016064e in init_mod (m=0xb7bc2a7c) at sr_module.c:883
#15 0x0016064e in init_mod (m=0xb7bc2ef4) at sr_module.c:883
#16 0x0016064e in init_mod (m=0xb7bc3430) at sr_module.c:883
#17 0x0016064e in init_mod (m=0xb7bc37a8) at sr_module.c:883
#18 0x0016064e in init_mod (m=0xb7bc3c2c) at sr_module.c:883
#19 0x0016064e in init_mod (m=0xb7bc3fa4) at sr_module.c:883
#20 0x0016064e in init_mod (m=0xb7bc4da0) at sr_module.c:883
#21 0x00161729 in init_modules () at sr_module.c:913
#22 0x00128957 in main (argc=7, argv=0xbffffd14) at main.c:2412
This is because db_do_query gets called (from permissions module when it
checks table version) before the database module was initialized (and
thus, db_query_init was not yet called).
Now, I'm not sure if the previous behaviour is to be required. But at
least we should not crash if the module ordering is not right.
Peter, please fix the code to either work as before, or give proper
error message and exit (instead of crashing).
Thanks,
Timo
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev