Hi,
I am observing the following sequence in kamailio 3.1.2 log files:
| ERROR: <core> [db.c:421]: invalid parameter value | DEBUG: siptrace [siptrace.c:530]: storing info... | ERROR: <core> [db_query.c:152]: invalid parameter value | ERROR: siptrace [siptrace.c:532]: error storing trace
It happens after executing t_uac_dlg via mi_datagram.
The interesting part of the configuration file is:
| event_route[tm:local-request]{ | xlog("L_NOTICE", "event_route tm:local-request ..."); | sip_trace(); | }
Both use_table and insert first check for NULL values among their parameters. The only common parameter to both functions is the db connection. I verified that it is actually NULL as it arrives in db_use_table (lib/srdb1/db.c).
So why should the db_con module level variable (modules_k/siptrace/siptrace.c) be uninitialized? This question is answered in the child_init function of the same file: The db_con is not initialized if the passed rank is one out of PROC_INIT, PROC_MAIN and PROC_TCP_MAIN.
Might be a good point to look at mi_datagram's child_init (modules_k/mi_datagram/mi_datagram.c). Well yeah. It forks of a process when rank is PROC_MAIN. And that process has no db_con in the siptrace module. So logging from mi_datagram is doomed to fail.
An obvious idea is to open up a database connection for PROC_MAIN, too. The db_con would then (with luck) be inherited to the mi_datagram module and in fact this happens on my instance.
The sharing of a db_con with multiple processes is obviously not that a brilliant idea. Nasty race conditions can occur later. So how to solve this issue instead of working around the symptoms?
Helmut