<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'Lucida Console'; font-size:9pt; font-weight:400; font-style:normal;">On Mittwoch, 30. September 2009, Alex Balashov wrote:<br>
> BTW, for what it's worth: these effects have not been observed when<br>
> using db_postgres instead.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Hi Alex,<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>ok, this is perhaps because the postgres code uses another escape function which is probably more stable against invalid input, or the escape is not used in this case at all. (It looks like your crash was in the function mysql_real_escape_string)<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>One reason that it needs some time to crash could be that every process has its own database handle open, and because of the blocking different processes gets the request from time to time, until it find the "right" one that cause a crash.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Do you use allow_trusted in caching mode, or does it query the db for every invocation? If the latter, i'd take a closer look to the failure handling logic in the function, perhaps it lets some variables staying in a unclean state after a failure.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Cheers,<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Henning<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p><p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> > I've run into a bug in Kamailio 1.4.4 where, if using the permissions<br>
> > module with db_mysql the database becomes unavailable, Kamailio will<br>
> > crash (SIGSEGV) somewhat arbitrarily after about 30-45 seconds. The<br>
> > process is a little random; sometimes it can take longer.<br>
> ><br>
> > At first, I suspected the problem may be with 1.4.x, but got the exact<br>
> > same effect when trying 1.5.2. I also assumed the problem may be with<br>
> > db_mysql or even libmysqlclient, but when I remove the permissions<br>
> > functionality from the configuration the process does not crash. This<br>
> > is a configuration from the 1.4.x era with a lot of custom DB queries<br>
> > via avp_db_query() (pre-sqlops); when the database disappears, Kamailio<br>
> > will complain loudly in the logs, of course, but it will not crash<br>
> > unless I am calling allow_trusted() as part of the configuration and am<br>
> > using the permissions module with database backing.<br>
> ><br>
> > The test system is CentOS 4.7 64-bit, but I've reproduced the problem on<br>
> > Debian lenny and unstable just as easily with libmysqlclient15.<br>
> ><br>
> > Here are my steps for producing the bug:<br>
> ><br>
> > 1) Initialise Kamailio (the only modules that use database are<br>
> > permissions and avpops);<br>
> ><br>
> > 2) Firewall MySQL database off or shut it down;<br>
> ><br>
> > 3) Place a call - even one will do;<br>
> ><br>
> > 4) Kamailio will not crash immediately; it usually takes several<br>
> > request retransmissions or successive attempts to contact the database<br>
> > for this to happen, and it can take close to a minute. Eventually,<br>
> > though, there is a segfault that appears to be bubbling up from<br>
> > allow_trusted() in the call stack.<br>
> ><br>
> > Here is the backtrace. IP addresses and phone numbers are sanitised to<br>
> > protect confidentiality, but have been substituted consistently:<br>
> ><br>
> > (gdb) where<br>
> > 0 0x00000030eba21b70 in mysql_real_escape_string ()<br>
> > from /usr/lib64/mysql/libmysqlclient.so.15<br>
> > 1 0x0000002a95be64c1 in db_mysql_val2str (_c=0x686e60, _v=0x7fbfffd900,<br>
> > _s=0x6331a7 "222.22.222.22'", _len=0x7fbfffd2cc) at val.c:233<br>
> > 0000002 0x00000000004b2f14 in db_print_where (_c=0x686e60,<br>
> > _b=0x63319f "src_ip='222.22.222.22'", _l=65473, _k=0x7fbfffd440,<br>
> > _o=0x0,<br>
> > _v=0x7fbfffd900, _n=1, val2str=0x2a95be62ca <db_mysql_val2str>)<br>
> > at db/db_ut.c:275<br>
> > 0000003 0x00000000004affb8 in db_do_query (_h=0x686e60, _k=0x7fbfffd440,<br>
> > _op=0x0,<br>
> > _v=0x7fbfffd900, _c=Variable "_c" is not available.<br>
> > ) at db/db_query.c:78<br>
> > 0000004 0x0000002a95be2dbf in db_mysql_query (_h=0x0, _k=0x6331a7,<br>
> > _op=0x2a962492a0, _v=0xe, _c=0x7fbfffd900, _n=6844000, _nc=0, _o=0x0,<br>
> > _r=0x0) at dbase.c:249<br>
> > 0000005 0x0000002a961428c0 in allow_trusted (msg=0x687038,<br>
> > src_ip=0x2a962492a0 "222.22.223.23", proto=1) at trusted.c:422<br>
> > 0000006 0x0000002a96143356 in allow_trusted_0 (_msg=0x687038,<br>
> > str1=Variable "str1" is not available.<br>
> > )<br>
> > at ../../parser/../ip_addr.h:398<br>
> > 0000007 0x000000000040d4df in do_action (a=0x6566f8, msg=0x687038) at<br>
> > action.c:850<br>
> > 0000008 0x000000000040ec2b in run_action_list (a=Variable "a" is not<br>
> > available.<br>
> > ) at action.c:138<br>
> > 0000009 0x00000000004523dc in eval_expr (e=0x6567c8, msg=0x687038,<br>
> > val=0x0) at route.c:1116<br>
> > 0000010 0x00000000004527c2 in eval_expr (e=0x656810, msg=0x687038,<br>
> > val=0x0) at route.c:1429<br>
> > 11 0x0000000000452159 in eval_expr (e=0x656858, msg=0x687038, val=0x0)<br>
> > at route.c:1434<br>
> > 12 0x000000000040c933 in do_action (a=0x656e70, msg=0x687038) at<br>
> > action.c:705<br>
> > 13 0x000000000040ec2b in run_action_list (a=Variable "a" is not<br>
> > available. ) at action.c:138<br>
> > 14 0x000000000040e95f in do_action (a=0x657f00, msg=0x687038) at<br>
> > action.c:728<br>
> > 15 0x000000000040ec2b in run_action_list (a=Variable "a" is not<br>
> > available. ) at action.c:138<br>
> > 16 0x000000000040e95f in do_action (a=0x657fd0, msg=0x687038) at<br>
> > action.c:728<br>
> > 17 0x000000000040ec2b in run_action_list (a=Variable "a" is not<br>
> > available. ) at action.c:138<br>
> > 18 0x000000000040ef30 in run_top_route (a=0x651008, msg=0x687038)<br>
> > at action.c:118<br>
> > ---Type <return> to continue, or q <return> to quit---<br>
> > 19 0x00000000004467ef in receive_msg (<br>
> > buf=0x622ac0 "INVITE sip:8005551212@123.132.132.7:5060;transport=udp<br>
> > SIP/2.0\r\nRecord-Route:<br>
> > <sip:222.22.223.23;lr;rpdicor=VPSF506071629460;vsf=AAAAAB0GDgULBQIABgJ3AW<br>
> >4CFhgKGwIbARoJNDg->\r\nRecord-Route: <sip:90.148.216.254"..., len=922,<br>
> > rcv_info=0x7fbffff700) at receive.c:165 0000020 0x0000000000480c44<br>
> > in udp_rcv_loop () at udp_server.c:449 21 0x0000000000422b4f in main<br>
> > (argc=Variable "argc" is not available. ) at main.c:692<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p><p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p></body></html>