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

[Peter Dunkley]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20111030/b41460c1/attachment.htm>