[OpenSIPS-Users] What is protocol/port mismatch?

Thu Feb 4 10:10:09 CET 2010

Hi Brian,

The backtrace from gdb seams really corrupted, but the pstack output is 
a bit consistent.
What is strange is that dlg_validate_dialog () seams to call 
fm_realloc() which is not in the script.

So, to eliminate any possibility of a mem corruption (the crash was in 
the mem manager), I suggest to compile the mem debugger to see if there 
are no mem issues (mem overwritten, double free, etc).

Regards,
Bogdan

opensipslist at encambio.com wrote:
> Hello Bogdan,
>
> An mer., févr 03, 2010, Bogdan-Andrei Iancu schrieb:
>   
>> Regarding the crash you mentioned - do you have any backtraces ?
>>
>>     
> There's quite a lot of situations in which OpenSIPS crashes, so
> I'm not sure this one is related to TLS traffic arriving on a non
> TLS port. In any case, here's the last backtrace:
>
> $ gdb /pfx/sbin/opensips opensips.17272.name.host.tld.core 
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i386-pc-solaris2.11"...
> (no debugging symbols found)
> Cannot access memory at address 0x70795464
> (gdb) bt
> #0  0x0810eefc in fm_realloc ()
> #1  0xd0d8cc8c in ?? ()
> #2  0x080465a8 in ?? ()
> #3  0xd0d859d4 in ?? ()
> #4  0x08353c2c in mem_pool ()
> #5  0x00000191 in ?? ()
> #6  0x08046640 in ?? ()
> #7  0xffffffff in ?? ()
> #8  0xffffffff in ?? ()
> #9  0x080467d8 in ?? ()
> #10 0x08046638 in ?? ()
> #11 0x0812437e in parse_min_se ()
> #12 0x083132e0 in mem_pool ()
> #13 0xffffffff in ?? ()
> #14 0x81af694b in ?? ()
> #15 0xd0d8c6fc in ?? ()
> #16 0x00000001 in ?? ()
> #17 0x08353c2c in mem_pool ()
> #18 0xce43365d in ?? ()
> #19 0x080467c4 in ?? ()
> #20 0x0804678c in ?? ()
> #21 0x08353f9c in mem_pool ()
> #22 0x08046640 in ?? ()
> #23 0x08353f9c in mem_pool ()
> #24 0x00000073 in ?? ()
> #25 0x082ff8e8 in ?? ()
> #26 0xd13dbbe9 in ?? ()
> #27 0x00000002 in ?? ()
> #28 0x082ff8f0 in ?? ()
> #29 0x00003332 in ?? ()
> #30 0x00000000 in ?? ()
> (gdb)
>
> $ pstack opensips.17272.name.host.tld.core core 'opensips.17272.name.host.tld.core' of 17272:        /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
>  0810eefc fm_realloc (0, 80467cc, 0, 80467d8, d10f0000, 8354104) + 4bc
>  d1011537 dlg_validate_dialog (8353c2c, ce4334b0, 8046a38, d101459b, ce4334b0, 8323390) + 290
>  d10035ba w_validate_dialog (8353c2c, 0, 0, 0, 0, 0) + 2a
>  08076240 do_action (8323390, 8353c2c, 7275652e, 8046c00, 8046bf0, 0) + 15a5
>  08079877 run_action_list (8323390, 8353c2c, 844f7c8, 844f735, 83132ba, 13) + 281
>  080d03a7 eval_expr (83233fc, 8353c2c, 0, 0, 313c5, 1) + 46a
>  080d014a eval_expr (8323428, 8353c2c, 0, 0, 0, 0) + 20d
>  080d0019 eval_expr (8323454, 8353c2c, 0, d0ff18b3, 0, 8354890) + dc
>  080d0172 eval_expr (8323480, 8353c2c, 0, 8354700, 8354a2c, 27) + 235
>  0807643d do_action (83238cc, 8353c2c, 40, 82b1c50, 80472d4, 80472d4) + 17a2
>  08079877 run_action_list (83238cc, 8353c2c, 0, 81aaf92, 82b1c50, ce4350a8) + 281
>  08078381 do_action (832536c, 8353c2c, ce415b0d, d0dadd84, ce433690, ce415b08) + 36e6
>  08079877 run_action_list (832536c, 8353c2c, 0, 0, 0, 0) + 281
>  08078381 do_action (8325654, 8353c2c, ce415790, 0, 8353c30, 1) + 36e6
>  08079877 run_action_list (832108c, 8353c2c, d106ea15, 8344074, 8353c2c, 0) + 281
>  08079c50 get_bl_head_by_name (832108c, 8353c2c, 8353c2c, 80478f0, 308, 8353c2c) + f3
>  080be5aa receive_msg (ce415808, 308, ce4157a0, 80478d4, ce375d9c, 2) + 5ac
>  080f4cf4 tcp_read_req (ce415790, 8047978, d11d10c5, d11bfa64, 17, ce375d4c) + 18c
>  080f687d ???????? (b, d001, 8047ac4, d06e7e60, d06e9ae0, 831a84c)
>  080f77a4 tcp_receive_loop (c, 2, 0, 8047b10, 9, 0) + 94b
>  080ed6f8 tcp_send (82cb1f4, 138a, 83178e8, 805f130, d1169cc8, 8047c5c) + 4b
>  08091d47 main     (80749c0, 3, 8047bdc) + 3bab
>  080749c0 do_assign (3, 8047cc4, 8047cd8, 8047cdb, 0, 8047cfb) + d0
>
> $ pflags opensips.17272.name.host.tld.core
> core 'opensips.17272.name.host.tld.core' of 17272:        /pfx/sbin/opensips -P /pfx/var/opensips/opensips.pid
>         data model = _ILP32  flags = ORPHAN|MSACCT|MSFORK
>  /1:    flags = 0
>         sigmask = 0xffffbefc,0x0000ffff  cursig = SIGSEGV
>
>   
>> 1) t_relay() is not forcing any proto by itself: it preserves the 
>> inbound proto if the RURI (or socket) is not saying otherwise.
>>
>>     
> Okay, then I assume the t_relay() tried sending TLS traffic to
> the voicemail server, could not negotiate a TLS connection, and
> so resent the message over UDP instead. Is that right? Does
> t_relay() choose UDP instead of TCP when its first choice (the
> preserved inbound proto) cannot be used?
>
>   
>> 2) turning off the double RR may brake some things as opensips will
>> not be able to properly route between the original inbound and
>> outbound interfaces... only if you do it manually from the script.
>>
>>     
> I've configured OpenSIPS to listen on only one interface, so I guess
> that I'm not affected by this breakage. Next I'll try to solve the
> problem another way without disabling double Record-Route headers.
>
>   
>> To me, the solution looks like a dirty hack, but if makes Asterisk
>> happy... what can I say :)
>>
>>     
> Now that I know more I'll try to solve it another way.
>
> Regards,
> Brian
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   

-- 
Bogdan-Andrei Iancu
www.voice-system.ro