[OpenSIPS-Users] opensips 1.6.1 crashes on NOTIFY?

Alexander goal81 at gmail.com
Tue Dec 22 12:23:48 CET 2009


  What about this one:

Program terminated with signal 11, Segmentation fault.
[New process 15892]
#0  0x00e1fddb in t_lookup_request (p_msg=0x81d2f20, leave_new_locked=1) at
../../mem/../hash_func.h:65
65                      for (p=s2->s; p<=(end-4); p+=4){
(gdb) bt
#0  0x00e1fddb in t_lookup_request (p_msg=0x81d2f20, leave_new_locked=1) at
../../mem/../hash_func.h:65
#1  0x00e21859 in t_newtran (p_msg=0x81d2f20) at t_lookup.c:1051
#2  0x00e243a0 in w_t_newtran (p_msg=0x81d2f20, foo=0x0, bar=0x0) at
tm.c:1006
#3  0x080545dd in do_action (a=0x81cc30c, msg=0x81d2f20) at action.c:967
#4  0x08057308 in run_action_list (a=0x81cc30c, msg=0x81d2f20) at
action.c:139
#5  0x080af2be in eval_expr (e=0x81cc378, msg=0x81d2f20, val=0x0) at
route.c:1240
#6  0x080aed39 in eval_expr (e=0x81cc3a4, msg=0x81d2f20, val=0x0) at
route.c:1553
#7  0x080aeccf in eval_expr (e=0x81cc3d0, msg=0x81d2f20, val=0x0) at
route.c:1558
#8  0x080533c2 in do_action (a=0x81cc770, msg=0x81d2f20) at action.c:689
#9  0x08057308 in run_action_list (a=0x81cc770, msg=0x81d2f20) at
action.c:139
#10 0x080554a7 in do_action (a=0x81c85b4, msg=0x81d2f20) at action.c:119
#11 0x08057308 in run_action_list (a=0x81c85b4, msg=0x81d2f20) at
action.c:139
#12 0x080554dd in do_action (a=0x81c868c, msg=0x81d2f20) at action.c:706
#13 0x08057308 in run_action_list (a=0x81c868c, msg=0x81d2f20) at
action.c:139
#14 0x08056625 in do_action (a=0x81c86f8, msg=0x81d2f20) at action.c:712
#15 0x08057308 in run_action_list (a=0x81c86f8, msg=0x81d2f20) at
action.c:139
#16 0x08056625 in do_action (a=0x81c8764, msg=0x81d2f20) at action.c:712
#17 0x08057308 in run_action_list (a=0x81c8764, msg=0x81d2f20) at
action.c:139
#18 0x08056625 in do_action (a=0x81c87d0, msg=0x81d2f20) at action.c:712
#19 0x08057308 in run_action_list (a=0x81c87d0, msg=0x81d2f20) at
action.c:139
#20 0x08056625 in do_action (a=0x81c883c, msg=0x81d2f20) at action.c:712
#21 0x08057308 in run_action_list (a=0x81c883c, msg=0x81d2f20) at
action.c:139
#22 0x08056625 in do_action (a=0x81c88a8, msg=0x81d2f20) at action.c:712
#23 0x08057308 in run_action_list (a=0x81c88a8, msg=0x81d2f20) at
action.c:139
#24 0x080554dd in do_action (a=0x81ca360, msg=0x81d2f20) at action.c:706
#25 0x08057308 in run_action_list (a=0x81bd578, msg=0x81d2f20) at
action.c:139
#26 0x080576a3 in run_top_route (a=0x81bd578, msg=0x81d2f20) at action.c:119
#27 0x0809ddf2 in receive_msg (
    buf=0x8192380 "NOTIFY sip:62.117.120.98 SIP/2.0\r\nVia: SIP/2.0/UDP
194.190.163.139:5061;branch=z9hG4bK-d5a4f117\r\nFrom: 206401 <
sip:206401 at 62.117.120.98
<sip%3A206401 at 62.117.120.98>>;tag=d825811556491d55o0\r\nTo:
<sip:62.117.120.98>\r\nCall-ID: d42b6"..., len=347, rcv_info=0xbfd71e84) at
receive.c:162
#28 0x080e5056 in udp_rcv_loop () at udp_server.c:492
#29 0x08070adf in main (argc=3, argv=0xbfd72094) at main.c:821

22 декабря 2009 г. 13:10 пользователь Anca Vamanu <anca at opensips.org>написал:

> Hi Alexander,
>
> Unless you modified the sources, this is not the right backtrace. The
> line numbers do not correspond with the ones in the trace.
>
> Regards,
>
> --
> Anca Vamanu
> www.voice-system.ro
>
>
> Alexander wrote:
> >   Oh, found one. Seems to be right core file. GDB says:
> >
> > #0  0x080fbb52 in parse_params (_s=0xec, _c=695, _h=0x81d44bc,
> > _p=0x1d4) at parser/../trim.h:61
> > #1  0x080f135f in parse_msg (buf=0xb61eacc4 "э>\035\bп╛\036╤",
> > len=135861088, msg=0x305) at parser/msg_parser.c:567
> > #2  0x080ed9c7 in aaa_prot_bind (aaa_url=0xb61eacac, prot=0x80) at
> > aaa/aaa.c:85
> > #3  0x003b9205 in ?? ()
> > #4  0xb61eacac in ?? ()
> > #5  0x00000080 in ?? ()
> > #6  0x003e2df4 in ?? ()
> > #7  0x371f3654 in ?? ()
> > #8  0x00000007 in ?? ()
> > #9  0x08180e85 in _tr_buffer ()
> > #10 0x08180e81 in _tr_buffer ()
> > #11 0x00000000 in ?? ()
> >
> > 2009/12/22 Alexander <goal81 at gmail.com <mailto:goal81 at gmail.com>>
> >
> >       I have no core file for now:
> >
> >
> >     Dec 22 11:02:08 srv opensips[26182]: INFO:core:handle_sigs: core
> >     was not generated
> >
> >       Strange - "ulimit -c unlimited" and calls to setrlimit() in
> >     OpenSIPS produce no core file.
> >
> >       NOTIFY packets come from clients. Also, Opensips sometimes sends
> >     keepalive NOTIFY packets, but my route(5) is called inside "uri ==
> >     myself" section.
> >
> >     2009/12/22 Anca Vamanu <anca at opensips.org <mailto:anca at opensips.org
> >>
> >
> >         Hi Alexander,
> >
> >         Can you please investigate the core with gdb and print here
> >         the output.
> >         It seems awkward to me that you expect to receive Notifies and
> >         reply to
> >         them. Wat kind of notifies are those? Sent by clients or the
> >         presence
> >         server?
> >
> >         Regards,
> >         Anca
> >
> >
> >
> >         Alexander wrote:
> >         >   Hi all.
> >         >
> >         >   I've tried to update to Opensips 1.6.1, but encountered the
> >         > following problem. Opensips starts successfully, but soon
> >         almost all
> >         > it's processes die one by one and only two processes remain.
> >         > For example, if right after start we have:
> >         >
> >         > # ps ax | grep opens
> >         > 26182 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26183 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26184 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26185 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26186 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26187 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26188 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26189 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26190 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26191 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26192 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26193 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26194 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26195 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26196 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26197 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26198 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26199 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26200 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26201 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26202 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26203 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26204 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26205 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26206 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26207 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26208 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         >
> >         >   When processes die, we have only:
> >         >
> >         > #ps ax | grep opens
> >         > 26182 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         > 26184 ?        S      0:00 ./opensips -k 0x11110204 -u opensips
> >         >
> >         >   If I set debug=6, the following is written to
> >         /var/log/messages:
> >         >
> >         > Dec 22 11:02:03 srv rtpproxy[17011]: INFO:rxmit_packets:
> >         caller's
> >         > address filled in: 195.182.195.206:1024
> >         <http://195.182.195.206:1024> <http://195.182.195.206:1024>
> >         > (RTP)
> >         > Dec 22 11:02:03 srv opensips[26184]: Route 5 - NOTIFY
> >         > Dec 22 11:02:05 srv opensips[26185]: Route 5 - PUBLISH
> >         > Dec 22 11:02:06 srv opensips[26183]: Route 5 - NOTIFY
> >         > Dec 22 11:02:06 srv opensips[26185]: Route 5 - NOTIFY
> >         > Dec 22 11:02:06 srv opensips[26185]: Route 5 - NOTIFY
> >         > Dec 22 11:02:06 srv opensips[26186]: Route 5 - NOTIFY
> >         > Dec 22 11:02:06 srv opensips[26186]: Route 5 - NOTIFY
> >         > Dec 22 11:02:08 srv rtpproxy[17011]: INFO:handle_command:
> >         lookup on
> >         > ports 36664/35096, session timer restarted
> >         > Dec 22 11:02:08 srv rtpproxy[17011]: INFO:handle_command:
> >         pre-filling
> >         > callee's address with 87.251.142.50:5006
> >         <http://87.251.142.50:5006> <http://87.251.142.50:5006>
> >         > Dec 22 11:02:08 srv opensips[26208]:
> >         CRITICAL:core:receive_fd: EOF on 13
> >         > Dec 22 11:02:08 srv opensips[26182]: INFO:core:handle_sigs:
> >         child
> >         > process 26186 exited by a signal 11
> >         > Dec 22 11:02:08 srv opensips[26182]: INFO:core:handle_sigs:
> >         core was
> >         > not generated
> >         > Dec 22 11:02:08 srv opensips[26182]: INFO:core:handle_sigs:
> >         > terminating due to SIGCHLD
> >         >
> >         >   As I see, the last message received by process with PID
> >         26186 is
> >         > NOTIFY, and then it crashes.
> >         >
> >         > "Route 5 - NOTIFY" is in this block of configuration file:
> >         >
> >         > # SUBSCRIBE and PUBLISH Message Handling
> >         > # --------------------------------------
> >         > route[5]
> >         > {
> >         >     if (!t_newtran())
> >         >     {
> >         >         xlog("L_INFO", "Failed to create transaction\n");
> >         >         sl_reply_error();
> >         >         exit;
> >         >     }
> >         >
> >         >     if (is_method("PUBLISH"))
> >         >     {
> >         >         xlog("L_INFO", "Route 5 - PUBLISH \n");
> >         >         handle_publish();
> >         >     }
> >         >     else if (is_method("SUBSCRIBE"))
> >         >     {
> >         >         xlog("L_INFO", "Route 5 - SUBSCRIBE\n");
> >         >         handle_subscribe();
> >         >     }
> >         >     else if (is_method("NOTIFY"))
> >         >     {
> >         >         xlog("L_INFO", "Route 5 - NOTIFY\n");
> >         >         t_reply("200", "OK");
> >         >         exit;
> >         >     }
> >         >
> >         >     exit;
> >         > }
> >         >
> >         >   In main routing logic:
> >         >
> >         > if (method == "SUBSCRIBE" || method == "PUBLISH" || method
> >         == "NOTIFY")
> >         > {
> >         >     route(4);
> >         >     return(0);
> >         > }
> >         >
> >         >   As I see, Opensips sets core dump limit, if it's turned
> >         off, but no
> >         > core is produced (OS is CentOS 5.3).
> >         >
> >         >   What can be wrong? Version 1.6.0 did not crash like this.
> >         >
> >
> ------------------------------------------------------------------------
> >         >
> >         > _______________________________________________
> >         > Users mailing list
> >         > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >         > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >         >
> >
> >
> >         --
> >         Anca Vamanu
> >         www.voice-system.ro <http://www.voice-system.ro>
> >
> >
> >         _______________________________________________
> >         Users mailing list
> >         Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20091222/a1dc48c6/attachment-0001.htm 


More information about the Users mailing list