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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev