THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#137 - app_python doesn't work
User who did this - Michal Karas (Largon)
----------
Sorry, I should have been more clear.
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=137#comment316
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#137 - app_python doesn't work
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Fixed
Additional comments about closing: Patch applied.
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=137
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#137 - app_python doesn't work
User who did this - Daniel-Constantin Mierla (miconda)
----------
I just applied you patch. Took a while because initially I thought it was duplicate of initial report and forgot about it since I haven't spotted is actually a request to reopen, but a new issue which I didn't find in the list.
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=137#comment315
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has been re-opened:
FS#137 - app_python doesn't work
User who did this - Daniel-Constantin Mierla (miconda)
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=137
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
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