[sr-dev] siptrace failure when used from mi_datagram

Daniel-Constantin Mierla miconda at gmail.com
Wed Jun 15 14:22:21 CEST 2011


this is a known issue since the sip_trace is not initialized for 
mi_datagram processes so there is no db connection for siptrace in that 
process -- it is in my todo list to review it and find a solution, but 
there was no time for it so far.

Meanwhile, you can try to change in:


line 280:

pid=fork_process(PROC_NOCHLDINIT, "MI DATAGRAM", 1);


pid=fork_process(PROC_RPC, "MI DATAGRAM", 1);


On 6/15/11 1:08 PM, Helmut Grohne wrote:
> 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
> 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
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda

More information about the sr-dev mailing list