[sr-dev] siptrace failure when used from mi_datagram

[Helmut Grohne]

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