Hi Alex, updating from 1.6 SVN branch, are these crashes still happening ?
Regards, Bogdan Alexander wrote: > Any ideas? I'm afraid to touch something and make things worse :) > > 22 декабря 2009 г. 14:23 пользователь Alexander <[email protected] > <mailto:[email protected]>> написал: > > 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:[email protected] > <mailto:sip%[email protected]>>;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 > <[email protected] <mailto:[email protected]>> написал: > > 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 <http://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 <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > > > 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 <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > > > 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> <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> <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 > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > > -- > > Anca Vamanu > > www.voice-system.ro <http://www.voice-system.ro> > <http://www.voice-system.ro> > > > > > > _______________________________________________ > > Users mailing list > > [email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > [email protected] <mailto:[email protected]> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] <mailto:[email protected]> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
