[SR-Users] Segmentation Fault encountered in pv.so

Simpson Chua simpsonchua at yahoo.com
Fri Feb 17 21:02:08 CET 2012


Hi,

Since I am getting errors in from the usrloc module, I am trying another way to parse out the information I need using pv.so.
I'm encountering similar segfaults issues. Here are snippets of my configs:

modparam("sipcapture", "db_url", "mysql://xxx:xxx@localhost/test_db")
modparam("sipcapture", "capture_on", 1)
modparam("sipcapture", "table_name", "sip_capture")
modparam("sipcapture", "raw_socket_listen", "127.0.0.1:5060-9000")
modparam("sipcapture", "raw_interface", "eth2")
modparam("sipcapture", "raw_sock_children", 4)
modparam("sipcapture", "raw_moni_capture_on", 1)
modparam("sipcapture", "promiscious_on", 1)

route {
        if (method == "REGISTER") {
if (avp_check("$si","eq/10.xxx.xxx.xxx")) {
#save("location", "0x04"); # This currently results in segfault and is being addressed by Alexandr
sip_capture();
xlog("The received IP is $Ri\n"); # Just to test if I am able to parse the received IP from the Via headers correctly
drop;
}
drop;
}
}

Feb 17 13:41:02 ubuntu kernel: [251382.760104] kamailio[9414]: segfault at 31 ip 00007fb4ef077611 sp 00007fff0c8a6468 error 4 in pv.so[7fb4ef06a000+39000]


Core was generated by `kamailio -w /home/core'.
Program terminated with signal 11, Segmentation fault.
#0  pv_get_rcvip (msg=0x7fb4efdd7598, param=0x7fb4efdcef88, res=0x7fff0c8a64b0) at pv_core.c:647
647                             || msg->rcv.bind_address->address_str.s==NULL)

(gdb) bt
#0  pv_get_rcvip (msg=0x7fb4efdd7598, param=0x7fb4efdcef88, res=0x7fff0c8a64b0) at pv_core.c:647
#1  0x000000000049b5ad in pv_get_spec_value (msg=0x7fb4efdd7598, sp=0x7fb4efdcef70, value=0x7fff0c8a64b0) at pvapi.c:1180
#2  0x000000000049b71d in pv_printf (msg=0x7fb4efdd7598, list=<optimized out>, buf=<optimized out>, len=0x7fff0c8a6558) at pvapi.c:1239
#3  0x00007fb4ed0d442e in xlog_helper (msg=<optimized out>, xm=0x7fb4efdceef0, level=-1, line=0) at xlog.c:168
#4  0x000000000041babb in do_action (h=0x7fff0c8a73b0, a=0x7fb4efdd02a0, msg=0x7fb4efdd7598) at action.c:1122
#5  0x000000000041abe2 in run_actions (h=0x7fff0c8a73b0, a=0x7fb4efdd0080, msg=0x7fb4efdd7598) at action.c:1610
#6  0x000000000041c05b in do_action (h=0x7fff0c8a73b0, a=0x7fb4efdd10d0, msg=0x7fb4efdd7598) at action.c:1107
#7  0x000000000041abe2 in run_actions (h=0x7fff0c8a73b0, a=0x7fb4efdd10d0, msg=0x7fb4efdd7598) at action.c:1610
#8  0x000000000041c05b in do_action (h=0x7fff0c8a73b0, a=0x7fb4efdd1350, msg=0x7fb4efdd7598) at action.c:1107
#9  0x000000000041abe2 in run_actions (h=0x7fff0c8a73b0, a=0x7fb4efdd1350, msg=0x7fb4efdd7598) at action.c:1610
#10 0x0000000000422fa2 in run_top_route (a=0x7fb4efdd1350, msg=0x7fb4efdd7598, c=<optimized out>) at action.c:1683
#11 0x00000000004b061e in receive_msg (buf=<optimized out>, len=<optimized out>, rcv_info=<optimized out>) at receive.c:207
#12 0x00007fb4edb538b0 in raw_capture_rcv_loop (rsock=5, port1=5060, port2=8933, ipip=0) at sipcapture.c:1518
#13 0x00007fb4edb53e1f in init_rawsock_children () at sipcapture.c:572
#14 0x00007fb4edb54033 in child_init (rank=<optimized out>) at sipcapture.c:542
#15 0x0000000000507a0f in init_mod_child (m=0x7fb4efdcb2b0, rank=0) at sr_module.c:886
#16 0x0000000000507974 in init_mod_child (m=0x7fb4efdcb668, rank=0) at sr_module.c:883
#17 0x0000000000507974 in init_mod_child (m=0x7fb4efdcc178, rank=0) at sr_module.c:883
#18 0x0000000000507974 in init_mod_child (m=0x7fb4efdcc4b0, rank=0) at sr_module.c:883
#19 0x0000000000507974 in init_mod_child (m=0x7fb4efdccaf0, rank=0) at sr_module.c:883
#20 0x0000000000507974 in init_mod_child (m=0x7fb4efdcd030, rank=0) at sr_module.c:883
#21 0x0000000000476149 in main_loop () at main.c:1661
#22 0x000000000041a940 in main (argc=<optimized out>, argv=0x7fff0c8a7be8) at main.c:2475

(gdb) p *msg
$1 = {id = 82, pid = 9418, fwd_send_flags = {f = 0 '\000', blst_imask = 0 '\000'}, rpl_send_flags = {f = 0 '\000', blst_imask = 0 '\000'}, first_line = {
    type = 1, len = 43, u = {request = {method = {
          s = 0x7fb4edd57d2a "REGISTER sip:abc.def.com SIP/2.0\r\nFrom: \"9995551234\" <sip:9995551234 at abc.def.com;rp=SandboxTestingRegistrations>;tag=F9EEDA6C-E203EB89\r\nTo: <sip:9995551234 at abc.def.com>\r\nCal"..., len = 8}, uri = {
          s = 0x7fb4edd57d33 "sip:abc.def.com SIP/2.0\r\nFrom: \"9995551234\" <sip:9995551234 at abc.def.com;rp=SandboxTestingRegistrations>;tag=F9EEDA6C-E203EB89\r\nTo: <sip:9995551234 at abc.def.com>\r\nCall-ID: 225"..., len = 24}, version = {
          s = 0x7fb4edd57d4c "SIP/2.0\r\nFrom: \"9995551234\" <sip:9995551234 at abc.def.com;rp=SandboxTestingRegistrations>;tag=F9EEDA6C-E203EB89\r\nTo: <sip:9995551234 at abc.def.com>\r\nCall-ID: 2257e150-b49dfd8d-c8d924b2 at 1"..., len = 7}, method_value = 32}, reply = {version = {
          s = 0x7fb4edd57d2a "REGISTER sip:abc.def.com SIP/2.0\r\nFrom: \"9995551234\" <sip:9995551234 at abc.def.com;rp=SandboxTestingRegistrations>;tag=F9EEDA6C-E203EB89\r\nTo: <sip:9995551234 at abc.def.com>\r\nCal"..., len = 8}, status = {
          s = 0x7fb4edd57d33 "sip:abc.def.com SIP/2.0\r\nFrom: \"9995551234\" <sip:9995551234 at abc.def.com;rp=SandboxTestingRegistrations>;tag=F9EEDA6C-E203EB89\r\nTo: <sip:9995551234 at abc.def.com>\r\nCall-ID: 225"..., len = 24}, reason = {
          s = 0x7fb4edd57d4c "SIP/2.0\r\nFrom: \"9995551234\" <sip:9995551234 at abc.def.com;rp=SandboxTestingRegistrations>;tag=F9EEDA6C-E203EB89\r\nTo: <sip:9995551234 at abc.def.com>\r\nCall-ID: 2257e150-b49dfd8d-c8d924b2 at 1"..., len = 7}, statuscode = 32}}}, via1 = 0x7fb4efdd7ef0, 
  via2 = 0x7fb4efdd8218, headers = 0x7fb4efdd7e50, last_header = 0x7fb4efdd87c0, parsed_flag = 18446744073709551615, h_via1 = 0x7fb4efdd80d8, 
  h_via2 = 0x7fb4efdd8178, callid = 0x7fb4efdd19b0, to = 0x7fb4efdd1910, cseq = 0x7fb4efdd7c80, from = 0x7fb4efdd7e50, contact = 0x7fb4efdd84a0, 
  maxforwards = 0x7fb4efdd8680, route = 0x0, record_route = 0x0, content_type = 0x0, content_length = 0x7fb4efdd87c0, authorization = 0x0, 
  expires = 0x7fb4efdd8720, proxy_auth = 0x0, supported = 0x0, require = 0x0, proxy_require = 0x0, unsupported = 0x0, allow = 0x0, event = 0x0, accept = 0x0, 
  accept_language = 0x7fb4efdd85e0, organization = 0x0, priority = 0x0, subject = 0x0, user_agent = 0x7fb4efdd8540, server = 0x0, content_disposition = 0x0, 
  accept_disposition = 0x0, diversion = 0x0, rpid = 0x0, refer_to = 0x0, session_expires = 0x0, min_se = 0x0, sipifmatch = 0x0, subscription_state = 0x0, 
  date = 0x0, identity = 0x0, identity_info = 0x0, pai = 0x0, ppi = 0x0, path = 0x0, privacy = 0x0, body = 0x0, 
  eoh = 0x7fb4edd58036 "12963462\", realm=\"proxyApp\", nonce=\"proxyAppXgyrmj82aTujp3sdBW\", uri=\"sip:abc.def.com\", response=\"039891b3f5999b90a645d3e808c2147c\", algorithm=MD5, cnonce=\"l7/u88HtGJCOAmM\", qop=auth, nc="..., 
  unparsed = 0x7fb4edd58036 "12963462\", realm=\"proxyApp\", nonce=\"proxyAppXgyrmj82aTujp3sdBW\", uri=\"sip:abc.def.com\", response=\"039891b3f5999b90a645d3e808c2147c\", algorithm=MD5, cnonce=\"l7/u88HtGJCOAmM\", qop=auth, nc="..., rcv = {src_ip = {af = 2, len = 4, u = {addrl = {140411255757578, 
          4294967291}, addr32 = {184916746, 32692, 4294967291, 0}, addr16 = {39690, 2821, 32692, 0, 65531, 65535, 0, 0}, 
        addr = "\n\233\005\v\264\177\000\000\373\377\377\377\000\000\000"}}, dst_ip = {af = 2, len = 4, u = {addrl = {140414021193994, 5273972}, addr32 = {
          2950353162, 32692, 5273972, 0}, addr16 = {53514, 45018, 32692, 0, 31092, 80, 0, 0}, addr = "\n\321Ú¯\264\177\000\000tyP\000\000\000\000"}}, 
    src_port = 5060, dst_port = 5060, proto_reserved1 = 32692, proto_reserved2 = -266587208, src_su = {s = {sa_family = 2, 
        sa_data = "\023\304\n\233\005\v\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 184916746}, 
        sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 184916746, sin6_addr = {__in6_u = {
            __u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, 
    bind_address = 0x1, proto = 1 '\001'}, 
  buf = 0x7fb4edd57d2a "REGISTER sip:abc.def.com SIP/2.0\r\nFrom: \"9995551234\" <sip:9995551234 at abc.def.com;rp=SandboxTestingRegistrations>;tag=F9EEDA6C-E203EB89\r\nTo: <sip:9995551234 at abc.def.com>\r\nCal"..., len = 782, new_uri = {s = 0x0, len = 0}, dst_uri = {s = 0x0, len = 0}, 
  parsed_uri_ok = 1, parsed_uri = {user = {s = 0x0, len = 0}, passwd = {s = 0x0, len = 0}, host = {
      s = 0x7fb4edd57d37 "abc.def.com SIP/2.0\r\nFrom: \"9995551234\" <sip:9995551234 at abc.def.com;rp=SandboxTestingRegistrations>;tag=F9EEDA6C-E203EB89\r\nTo: <sip:9995551234 at abc.def.com>\r\nCall-ID: 2257e15"..., len = 20}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, 
    sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = SIP_URI_T, flags = 0, transport = {s = 0x0, len = 0}, ttl = {
      s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, 
      len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, 
    method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}}, parsed_orig_ruri_ok = 0, parsed_orig_ruri = {user = {s = 0x0, 
      len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, 
      len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = 0, transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, 
    user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, 
    transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {
      s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}}, add_rm = 0x0, body_lumps = 0x0, reply_lump = 0x0, 
  add_to_branch_s = '\000' <repeats 57 times>, add_to_branch_len = 0, hash_index = 0, msg_flags = 0, flags = 0, set_global_address = {s = 0x0, len = 0}, 
  set_global_port = {s = 0x0, len = 0}, force_send_socket = 0x0, path_vec = {s = 0x0, len = 0}}
  
(gdb) p *msg->rcv.bind_address
Cannot access memory at address 0x1

(gdb) 

Thanks,
Simpson


________________________________
 From: "sr-users-request at lists.sip-router.org" <sr-users-request at lists.sip-router.org>
To: sr-users at lists.sip-router.org 
Sent: Friday, February 17, 2012 7:34 AM
Subject: sr-users Digest, Vol 81, Issue 52
 
Send sr-users mailing list submissions to
    sr-users at lists.sip-router.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
or, via email, send a message with subject or body 'help' to
    sr-users-request at lists.sip-router.org

You can reach the person managing the list at
    sr-users-owner at lists.sip-router.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of sr-users digest..."


Today's Topics:

   1. Re: ndb_redis module fails after a while
      (Daniel-Constantin Mierla)
   2. Re: Kamailio Exits With: Segmentation Fault Error 4 in
      usrloc.so (Alexandr Dubovikov)


----------------------------------------------------------------------

Message: 1
Date: Fri, 17 Feb 2012 14:30:44 +0100
From: Daniel-Constantin Mierla <miconda at gmail.com>
Subject: Re: [SR-Users] ndb_redis module fails after a while
To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
    Users    Mailing List" <sr-users at lists.sip-router.org>
Cc: Javier Gallart <jgallartm at gmail.com>
Message-ID: <4F3E5684.3090203 at gmail.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

Hello,

right, very dummy paste position for resetting the redis context, use 
the attached patch or exchange lines 228 and 229. in redis_client.c

Thanks,
Daniel


On 2/17/12 1:13 PM, Javier Gallart wrote:
> Hi Daniel, Andrew
>
> I've just tested the patch and kamailio crashes when the redis server 
> is stopped. This is what I could get:
> -From the logs:
> Feb 17 06:33:32 r-gate-test ./kamailio[23812]: ALERT: <core> 
> [main.c:751]: child process 23819 exited by a signal 11
> Feb 17 06:33:32 r-gate-test ./kamailio[23812]: ALERT: <core> 
> [main.c:754]: core was generated
> Feb 17 06:33:32 r-gate-test ./kamailio[23812]: INFO: <core> 
> [main.c:766]: INFO: terminating due to SIGCHLD
>
> -An the backtrace:
> (...)
> Core was generated by `./kamailio -f ../etc/kamailio/kamailio.cfg'.
> Program terminated with signal 11, Segmentation fault.
> #0  redisFree (c=0x0) at hiredis.c:817
> 817   if (c->fd > 0)
> (gdb) bt
> #0  redisFree (c=0x0) at hiredis.c:817
> #1  0x00007f726f035461 in redisc_reconnect_server 
> (rsrv=0x7f7271c93ac0) at redis_client.c:229
> #2  0x00007f726f037240 in redisc_exec (srv=<value optimized out>, 
> cmd=0x7fffe98c6090, argv1=<value optimized out>, argv2=<value 
> optimized out>, argv3=<value optimized out>,
>     res=<value optimized out>) at redis_client.c:298
> #3  0x00007f726f034f7d in w_redis_cmd3 (msg=0x7f7271d7b018, 
> ssrv=<value optimized out>, scmd=<value optimized out>, 
> sres=0x7f7271d74b58 "h\341\313qr\177") at ndb_redis_mod.c:156
> #4  0x0000000000417025 in do_action (h=0x7fffe98c6570, 
> a=0x7f7271cc5248, msg=<value optimized out>) at action.c:1134
> #5  0x000000000041e58b in run_actions (h=<value optimized out>, 
> a=<value optimized out>, msg=<value optimized out>) at action.c:1610
> #6  0x000000000041e8d4 in run_actions_safe (h=0x7fffe98c7610, 
> a=0x7f7271c93781, msg=0x7f7271c93780) at action.c:1662
> #7  0x00000000004b731d in rval_get_int (h=0x7fffe98c7610, msg=0x0, 
> i=0x7fffe98c6bd8, rv=0x3, cache=0x4) at rvalue.c:920
> #8  0x00000000004bb87c in rval_expr_eval_int (h=0x7fffe98c7610, 
> msg=0x7f7271d7b018, res=0x7fffe98c6bd8, rve=0x7f7271cc6768) at 
> rvalue.c:1914
> #9  0x0000000000417c7c in do_action (h=0x7fffe98c7610, 
> a=0x7f7271ccb9d0, msg=<value optimized out>) at action.c:1092
> #10 0x000000000041e58b in run_actions (h=<value optimized out>, 
> a=<value optimized out>, msg=<value optimized out>) at action.c:1610
> #11 0x0000000000417cd7 in do_action (h=0x7fffe98c7610, 
> a=0x7f7271ccbb10, msg=<value optimized out>) at action.c:1111
> #12 0x000000000041e58b in run_actions (h=<value optimized out>, 
> a=<value optimized out>, msg=<value optimized out>) at action.c:1610
> #13 0x000000000041795e in do_action (h=0x7fffe98c7610, a=<value 
> optimized out>, msg=<value optimized out>) at action.c:732
> #14 0x000000000041e58b in run_actions (h=<value optimized out>, 
> a=<value optimized out>, msg=<value optimized out>) at action.c:1610
> #15 0x000000000041e862 in run_top_route (a=0x7f7271c94888, 
> msg=0x7f7271d7b018, c=<value optimized out>) at action.c:1683
> #16 0x0000000000498f36 in receive_msg (
>     buf=0x8bb100 "INVITE sip:34661574758 at 79.170.68.215:5060 
> <http://sip:34661574758@79.170.68.215:5060> SIP/2.0\r\nVia: 
> SIP/2.0/UDP 79.170.68.214:5060;branch=z9hG4bK-9451-1-0\r\nFrom: 
> 34661574758 <sip:34661574758 at 79.170.68.214:5060 
> <http://sip:34661574758@79.170.68.214:5060>>;tag=9451SIPpTag001\r\nTo: 
> sut <sip:"..., len=<value optimized out>, rcv_info=0x7fffe98c7910) at 
> receive.c:207
> #17 0x0000000000525987 in udp_rcv_loop () at udp_server.c:544
> #18 0x00000000004635f4 in main_loop () at main.c:1585
> #19 0x0000000000465e62 in main (argc=3, argv=0x7fffe98c7c08) at 
> main.c:2475
>
>
> Regards
>
> Javi
>
> On Fri, Feb 17, 2012 at 11:39 AM, Daniel-Constantin Mierla 
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>     thanks for testing, indeed it was an extra declaration left over.
>     Can you try with the new patch attached?
>
>     Cheers,
>     Daniel
>
>
>     On 2/17/12 11:10 AM, Andrew Pogrebennyk wrote:
>
>         Hi Daniel,
>
>         On 02/17/2012 10:47 AM, Daniel-Constantin Mierla wrote:
>
>             I made a patch for server reconnect -- I had no access to
>             a computer
>             with redis lib installed for the moment, hopefully it
>             compiles. If you
>             can try and tell the result, it would be great, I can
>             commit then.
>
>         I may be able to test this patch as well. Currently
>         compilations bails
>         out on attempt to redeclare redisc_reconnect_server function
>         parameter:
>
>         CC (gcc) [M ndb_redis.so]               ndb_redis_mod.o
>         CC (gcc) [M ndb_redis.so]               redis_client.o
>         redis_client.c: In function 'redisc_reconnect_server':
>         redis_client.c:206:19: error: 'rsrv' redeclared as different
>         kind of symbol
>         redis_client.c:202:46: note: previous definition of 'rsrv' was
>         here
>         make[1]: *** [redis_client.o] Error 1
>         make: *** [modules] Error 1
>
>         _______________________________________________
>         SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>         mailing list
>        sr-users at lists.sip-router.org
>         <mailto:sr-users at lists.sip-router.org>
>        http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>     -- 
>     Daniel-Constantin Mierla -- http://www.asipto.com
>    http://linkedin.com/in/miconda -- http://twitter.com/miconda
>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120217/1d77887f/attachment-0001.htm>
-------------- next part --------------
diff --git a/modules/ndb_redis/redis_client.c b/modules/ndb_redis/redis_client.c
index 9f4ffc4..234bb3a 100644
--- a/modules/ndb_redis/redis_client.c
+++ b/modules/ndb_redis/redis_client.c
@@ -199,6 +199,61 @@ redisc_server_t *redisc_get_server(str *name)
/**
  *
  */
+int redisc_reconnect_server(redisc_server_t *rsrv)
+{
+    char *addr;
+    unsigned int port, db;
+    param_t *pit = NULL;
+    struct timeval tv;
+
+    tv.tv_sec = 1;
+    tv.tv_usec = 0;
+    addr = "127.0.0.1";
+    port = 6379;
+    db = 0;
+    for (pit = rsrv->attrs; pit; pit=pit->next)
+    {
+        if(pit->name.len==4 && strncmp(pit->name.s, "addr", 4)==0) {
+            addr = pit->body.s;
+            addr[pit->body.len] = '\0';
+        } else if(pit->name.len==4 && strncmp(pit->name.s, "port", 4)==0) {
+            if(str2int(&pit->body, &port) < 0)
+                port = 6379;
+        } else if(pit->name.len==2 && strncmp(pit->name.s, "db", 2)==0) {
+            if(str2int(&pit->body, &db) < 0)
+                db = 0;
+        }
+    }
+    if(rsrv->ctxRedis!=NULL) {
+        redisFree(rsrv->ctxRedis);
+        rsrv->ctxRedis = NULL;
+    }
+
+    rsrv->ctxRedis = redisConnectWithTimeout(addr, port, tv);
+    if(!rsrv->ctxRedis)
+        goto err;
+    if (rsrv->ctxRedis->err)
+        goto err2;
+    if (redisCommandNR(rsrv->ctxRedis, "PING"))
+        goto err2;
+    if (redisCommandNR(rsrv->ctxRedis, "SELECT %i", db))
+        goto err2;
+
+    return 0;
+
+err2:
+    LM_ERR("error communicating with redis server [%.*s] (%s:%d/%d): %s\n",
+        rsrv->sname->len, rsrv->sname->s, addr, port, db, rsrv->ctxRedis->errstr);
+    return -1;
+err:
+    LM_ERR("failed to connect to redis server [%.*s] (%s:%d/%d)\n",
+        rsrv->sname->len, rsrv->sname->s, addr, port, db);
+    return -1;
+}
+
+/**
+ *
+ */
int redisc_exec(str *srv, str *cmd, str *argv1, str *argv2, str *argv3,
        str *res)
{
@@ -237,6 +292,14 @@ int redisc_exec(str *srv, str *cmd, str *argv1, str *argv2, str *argv3,
    c = cmd->s[cmd->len];
    cmd->s[cmd->len] = '\0';
    rpl->rplRedis = redisCommand(rsrv->ctxRedis, cmd->s);
+    if(rpl->rplRedis == NULL)
+    {
+        /* null reply, reconnect and try again */
+        if(redisc_reconnect_server(rsrv)==0)
+        {
+            rpl->rplRedis = redisCommand(rsrv->ctxRedis, cmd->s);
+        }
+    }
    cmd->s[cmd->len] = c;
    return 0;
}

------------------------------

Message: 2
Date: Fri, 17 Feb 2012 14:34:18 +0100
From: Alexandr Dubovikov <voip at start4.info>
Subject: Re: [SR-Users] Kamailio Exits With: Segmentation Fault Error
    4 in usrloc.so
To: miconda at gmail.com
Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\)
    - Users    Mailing List" <sr-users at lists.sip-router.org>
Message-ID: <4F3E575A.8070909 at start4.info>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

Hi Daniel,

ok, I will fix it in the sipcapture on this WE.

Wbr,
Alexandr

17.02.2012 14:26, Daniel-Constantin Mierla wrote:
> Hello,
>
> On 2/17/12 2:09 PM, Alexandr Dubovikov wrote:
>>
>> Hi,
>>
>> If i got it also correct:
>>
>> Simpson is getting SIP messages from a raw socket in the sipcapture 
>> module and try to save all REGISTER messages to the location table 
>> through the userloc module. (user registration audit)
>
> so sipcapture is executing the request route block from the config 
> even for packages received on the raw sockets. In this case it does 
> not set the socket and its string representation...
>
> Not sure yet the best place where it should be fixed: in usrloc (to 
> test for sock and sock_str) or in sipcapture, to set this fields as 
> most of the other config function. The second will be safer overall, 
> but might not be an usable socket for sending (if someone will attempt 
> to do lookup location and relay).
>
> Cheers,
> Daniel
>
>
>>
>> Wbr,
>> Alexandr
>>
>> 17.02.2012 13:49, Daniel-Constantin Mierla wrote:
>>> Hello,
>>>
>>> On 2/17/12 1:11 PM, Alexandr Dubovikov wrote:
>>>> Hi Daniel,
>>>>
>>>> he use raw_socket in the sipcapture module and save all REGISTER 
>>>> messages to location. (something like fraud controling for 
>>>> registration). I think in this case he have to ignore socket listener.
>>>
>>> not sure I understood -- it is on the server that saves to homer's 
>>> database? It gets the traffic over a raw socket and then executes 
>>> the config file as usual with functions from other modules?
>>>
>>> Cheers,
>>> Daniel
>>>
>>>>
>>>> Wbr,
>>>> Alexandr
>>>>
>>>>
>>>>
>>>>
>>>> 17.02.2012 09:19, Daniel-Constantin Mierla wrote:
>>>>> Hello,
>>>>>
>>>>> looks like an invalid listen socket structure, quite strange... 
>>>>> what version of kamailio do you have?
>>>>>
>>>>> Also, in gdb, frame 0, can you send the output of:
>>>>>
>>>>> p *_c
>>>>> p *_c->sock
>>>>>
>>>>> You can replace sensitive data (like IP), if you wish.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>> On 2/16/12 10:52 PM, Simpson Chua wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Kamailio is exiting with a segmentation fault when trying to do a 
>>>>>> save("location"). Here is some information I gathered.
>>>>>>
>>>>>> Feb 16 15:30:19 ubuntu /usr/local/sbin/kamailio[25721]: DEBUG: 
>>>>>> <core> [parser/msg_parser.c:103]: found end of header
>>>>>> Feb 16 15:30:19 ubuntu /usr/local/sbin/kamailio[25721]: ERROR: 
>>>>>> <core> [db.c:435]: invalid parameter value
>>>>>> Feb 16 15:30:19 ubuntu /usr/local/sbin/kamailio[25721]: ERROR: 
>>>>>> usrloc [udomain.c:564]: failed to use table location
>>>>>> Feb 16 15:30:19 ubuntu kernel: [171540.056663] kamailio[25721]: 
>>>>>> segfault at 89 ip 00007fa1f9a41452 sp 00007fff971a3af0 error 4 in 
>>>>>> usrloc.so[7fa1f9a37000+1f000]
>>>>>> Feb 16 15:30:19 ubuntu /usr/local/sbin/kamailio[25708]: ALERT: 
>>>>>> <core> [main.c:751]: child process 25720 exited by a signal 11
>>>>>> Feb 16 15:30:19 ubuntu /usr/local/sbin/kamailio[25708]: ALERT: 
>>>>>> <core> [main.c:754]: core was generated
>>>>>> Feb 16 15:30:19 ubuntu /usr/local/sbin/kamailio[25708]: INFO: 
>>>>>> <core> [main.c:766]: INFO: terminating due to SIGCHLD
>>>>>>
>>>>>> Core was generated by `kamailio -w /home/core'.
>>>>>> Program terminated with signal 11, Segmentation fault.
>>>>>> #0  db_insert_ucontact (_c=0x7f5f8f737eb0) at ucontact.c:474
>>>>>> 474                     vals[11].val.str_val = _c->sock->sock_str;
>>>>>> (gdb) bt
>>>>>> #0  db_insert_ucontact (_c=0x7f5f8f737eb0) at ucontact.c:474
>>>>>> #1  0x00007f5f916d9649 in insert_ucontact (_r=<optimized out>, 
>>>>>> _contact=<optimized out>, _ci=<optimized out>, _c=0x7fff52bbeb88) 
>>>>>> at urecord.c:473
>>>>>> #2  0x00007f5f914b785f in insert_contacts (_m=0x7f5f93d7f458, 
>>>>>> _d=0x7f5f8f72f680, _a=0x7fff52bbec00) at save.c:428
>>>>>> #3  0x00007f5f914b8d10 in add_contacts (_mode=1, 
>>>>>> _a=0x7fff52bbec00, _d=0x7f5f8f72f680, _m=0x7f5f93d7f458) at 
>>>>>> save.c:737
>>>>>> #4  save (_m=0x7f5f93d7f458, _d=0x7f5f8f72f680, _cflags=4) at 
>>>>>> save.c:790
>>>>>> #5  0x000000000041ba87 in do_action (h=0x7fff52bbf5d0, 
>>>>>> a=0x7f5f93d7f238, msg=0x7f5f93d7f458) at action.c:1128
>>>>>> #6  0x000000000041abe2 in run_actions (h=0x7fff52bbf5d0, 
>>>>>> a=0x7f5f93d7f238, msg=0x7f5f93d7f458) at action.c:1610
>>>>>> #7  0x000000000041c05b in do_action (h=0x7fff52bbf5d0, 
>>>>>> a=0x7f5f93d7fe08, msg=0x7f5f93d7f458) at action.c:1107
>>>>>> #8  0x000000000041abe2 in run_actions (h=0x7fff52bbf5d0, 
>>>>>> a=0x7f5f93d7fe08, msg=0x7f5f93d7f458) at action.c:1610
>>>>>> #9  0x0000000000422fa2 in run_top_route (a=0x7f5f93d7fe08, 
>>>>>> msg=0x7f5f93d7f458, c=<optimized out>) at action.c:1683
>>>>>> #10 0x00000000004b061e in receive_msg (buf=<optimized out>, 
>>>>>> len=<optimized out>, rcv_info=<optimized out>) at receive.c:207
>>>>>> #11 0x00007f5f91b038b0 in raw_capture_rcv_loop (rsock=5, 
>>>>>> port1=5060, port2=8933, ipip=0) at sipcapture.c:1518
>>>>>> #12 0x00007f5f91b03e1f in init_rawsock_children () at 
>>>>>> sipcapture.c:572
>>>>>> #13 0x00007f5f91b04033 in child_init (rank=<optimized out>) at 
>>>>>> sipcapture.c:542
>>>>>> #14 0x0000000000507a0f in init_mod_child (m=0x7f5f93d7b2b0, 
>>>>>> rank=0) at sr_module.c:886
>>>>>> #15 0x0000000000507974 in init_mod_child (m=0x7f5f93d7b668, 
>>>>>> rank=0) at sr_module.c:883
>>>>>> #16 0x0000000000507974 in init_mod_child (m=0x7f5f93d7c178, 
>>>>>> rank=0) at sr_module.c:883
>>>>>> #17 0x0000000000507974 in init_mod_child (m=0x7f5f93d7c4b0, 
>>>>>> rank=0) at sr_module.c:883
>>>>>> #18 0x0000000000476149 in main_loop () at main.c:1661
>>>>>> #19 0x000000000041a940 in main (argc=<optimized out>, 
>>>>>> argv=0x7fff52bbfd68) at main.c:2475
>>>>>>
>>>>>> Any idea why this is happening? Is there something in the 
>>>>>> REGISTER message that is causing this?
>>>>>>
>>>>>> Thanks,
>>>>>> Simpson
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>>>> sr-users at lists.sip-router.org
>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>> -- 
>>>>> Daniel-Constantin Mierla --http://www.asipto.com
>>>>> http://linkedin.com/in/miconda  -- http://twitter.com/miconda
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>>> sr-users at lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>
>>> -- 
>>> Daniel-Constantin Mierla --http://www.asipto.com
>>> http://linkedin.com/in/miconda  -- http://twitter.com/miconda
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>> -- 
>> Daniel-Constantin Mierla --http://www.asipto.com
>> http://linkedin.com/in/miconda  -- http://twitter.com/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120217/931efb00/attachment.htm>

------------------------------

_______________________________________________
sr-users mailing list
sr-users at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


End of sr-users Digest, Vol 81, Issue 52
****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120217/32a5f92b/attachment-0001.htm>


More information about the sr-users mailing list