[sr-dev] siptrace failure when used from mi_datagram

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