[OpenSIPS-Devel] Crash in OpenSIPS 2.1.4 (tm?)

[Răzvan Crainea]

Hi, Maxim!

 From the stacktrace you showed, it looks like OpenSIPS was trying to 
get a transaction lock, but somehow it crashes with an abort. Not sure 
why though, I couldn't find any documentation about that.

Is that the only process that crashes? It might be possible that another 
process crashes and destroys this one with an abort(). Can you double check?

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 03/07/2017 03:58 PM, Maxim Sobolev wrote:
> Răzvan, we are on FreeBSD there are no futexes on that OS. What's 
> wrong with using pthreads? It's been working for us before I think. 
> Thanks!
>
> -Max
>
> On Tue, Mar 7, 2017 at 12:20 AM, Răzvan Crainea <razvan at opensips.org 
> <mailto:razvan at opensips.org>> wrote:
>
>     Hi, Nick!
>
>     I see you are using pthreads locks, correct? Can you switch the
>     locking mechanism to FUTEX and check if it behaves differently?
>
>     Best regards,
>
>     Răzvan Crainea
>     OpenSIPS Solutions
>     www.opensips-solutions.com <http://www.opensips-solutions.com>
>
>     On 03/06/2017 06:59 PM, Maxim Sobolev wrote:
>>     The code leading to a crash is following:
>>
>>             /* lock reply processing to determine how to proceed
>>     reliably */
>>             LOCK_REPLIES( t );
>>
>>     We also see a lot of messages like this before the crash:
>>
>>     Mar  6 16:41:17 jenv_1 /usr/local/sbin/opensips[27453]:
>>     WARNING:core:utimer_ticker: utimer task <tm-utimer> already
>>     scheduled for 15365200 ms (now 15365390 ms), it may overlap..
>     ...
>
>>     Mar  6 16:41:18 jenv_1 /usr/local/sbin/opensips[27453]:
>>     WARNING:core:utimer_ticker: utimer task <tm-utimer> already
>>     scheduled for 15366070 ms (now 15366160 ms), it may overlap..
>>
>>     On Mon, Mar 6, 2017 at 8:51 AM, Maxim Sobolev
>>     <sobomax at sippysoft.com <mailto:sobomax at sippysoft.com>> wrote:
>>
>>         Hi folks,
>>
>>         We have observed the following crash in the OpenSIPS:
>>
>>         $ sudo gdb712 /usr/local/sbin/opensips ~/opensips.27455.core
>>         GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD]
>>         Core was generated by `opensips'.
>>         Program terminated with signal SIGABRT, Aborted.
>>         #0  0x0000000800ccf39a in thr_kill () from /lib/libc.so.7
>>         [Current thread is 1 (LWP 100588)]
>>         (gdb) bt
>>         #0  0x0000000800ccf39a in thr_kill () from /lib/libc.so.7
>>         #1  0x0000000800ccf386 in raise () from /lib/libc.so.7
>>         #2  0x0000000800ccf309 in abort () from /lib/libc.so.7
>>         #3  0x00000008009fe95a in ?? () from /lib/libthr.so.3
>>         #4  0x00000008009fa046 in ?? () from /lib/libthr.so.3
>>         #5  0x0000000801a148e1 in _lock (s=0x805003800) at lock.h:100
>>         #6  0x0000000801a14e84 in final_response_handler
>>         (fr_tl=0x805002078) at timer.c:389
>>         #7  0x0000000801a1664a in timer_routine (ticks=15362,
>>         set=0x0) at timer.c:1066
>>         #8  0x00000000004544dd in handle_timer_job () at timer.c:567
>>         #9  0x0000000000519920 in handle_io (fm=0x80142e670, idx=1,
>>         event_type=1) at net/net_udp.c:265
>>         #10 0x00000000005187ca in io_wait_loop_kqueue (h=0x8b6300
>>         <_worker_io>, t=1, repeat=0) at net/../io_wait_loop.h:281
>>         #11 0x0000000000519bed in udp_rcv_loop (si=0x80141ff98) at
>>         net/net_udp.c:308
>>         #12 0x000000000051a5c0 in udp_start_processes
>>         (chd_rank=0x7d56c8 <chd_rank>, startup_done=0x0) at
>>         net/net_udp.c:448
>>         #13 0x00000000004318a5 in main_loop () at main.c:731
>>         #14 0x0000000000433c79 in main (argc=9, argv=0x7fffffffe950)
>>         at main.c:1271
>>
>>         The opensips configuration is:
>>
>>                 if (method == "INVITE") {
>>                         if (!t_newtran()) {
>>         sl_reply_error();
>>                                 exit;
>>                         };
>>                 };
>>                 # Do strict routing if pre-loaded route headers present
>>                 if (loose_route() && !(method == "INVITE")) {
>>                         t_relay();
>>                         exit;
>>                 };
>>                 if ((!lookup("location") && method == "INVITE" && uri
>>         == myself) || uri == myself) {
>>         sl_send_reply("404", "Not Found");
>>                         exit;
>>                 };
>>                 if (method == "INVITE") {
>>                         record_route();
>>                 };
>>                 if (!t_relay()) {
>>                         sl_reply_error();
>>                 };
>>
>>         SIP exchange leading to this is below. It's basically case of
>>         the call that has been cancelled on the side A but INVITE got
>>         no provisional reply on side B.
>>
>>         -Max
>>
>
>     _______________________________________________
>     Devel mailing list
>     Devel at lists.opensips.org <mailto:Devel at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>     <http://lists.opensips.org/cgi-bin/mailman/listinfo/devel>
>
>
>
>
> -- 
> Maksym Sobolyev
> Sippy Software, Inc.
> Internet Telephony (VoIP) Experts
> Tel (Canada): +1-778-783-0474
> Tel (Toll-Free): +1-855-747-7779
> Fax: +1-866-857-6942
> Web: http://www.sippysoft.com
> MSN: sales at sippysoft.com <mailto:sales at sippysoft.com>
> Skype: SippySoft
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20170307/375c7afa/attachment-0001.html>