[sr-dev] "sql_buffer_size" causes crash in certain configurations

[Daniel-Constantin Mierla]

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

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20111101/c608d12f/attachment.htm>