[asterisk-bugs] [JIRA] (ASTERISK-27170) segfault in pj_sockaddr_in_set_str_addr

[George Joseph (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-27170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=238115#comment-238115 ] 

George Joseph commented on ASTERISK-27170:
------------------------------------------

Well, __copy_tls is copy thread local storage, another memory operation and in one of the backtraces you attached, the SEGV isn't actually caused by a write to an invalid location (which is usually the case) but an invalid size of 8 bytes so I'm still thinking there's something going on with memory management.   Recap for me please (because it's 5:30am and my eyes aren't fully open yet) when did the issue start happening?  If it's only been recently, can you narrow it down with a 'git bisect'?  Maybe we can at least find the commit that was the trigger.

For the backtraces, check {{/proc/sys/kernel/core_pattern}} and see where the default location for core dumps is.  I usually recommend setting it to somewhere specific like {{/var/log/coredumps/core-%e-%t}} which will result in {{/var/log/coredumps/core-asterisk-<timestamp>}}.  Also, I'd recommend disabling the abrt* stuff if you have it enabled.

We haven't seen any issues starting under valgrind either.  Exactly what valgrind options do you use.  I'll test it.


> segfault in pj_sockaddr_in_set_str_addr
> ---------------------------------------
>
>                 Key: ASTERISK-27170
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27170
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: PBX/General
>    Affects Versions: 13.16.0
>         Environment: 64bit linux musl 1.1.15
>            Reporter: nappsoft
>            Assignee: Unassigned
>         Attachments: crashlog.txt, trace_cel_crash.txt, trace.txt, valgrind2.txt
>
>
> From time to time asterisk crashes in pj_sockaddr_i_set_str_add. The asterisk version we use is 13.16.0 with some stability patches that flew into 13.17.0 (we will update to 13.17.0 soon). But we already had the same crashes with unpatched 13.16.0 versions and with older versions as well.
> According to the sip traces the last thing that happened was a sip transfer. The messageflow was:
> REFER (Phone) -> 202 Accepted (PBX) -> NOTIFY Trying (PBX) -> NOTIFY OK (PBX) -> BYE (Phone) - > OK (PBX for the BYE message) -> OK (Phone for the NOTIFY Trying) -> OK (Phone for the NOTIFY OK)
> As these are embedded systems with limited resources it's always difficult to make crash dumps there or to run asterisk in gdb... I'll try to get some complete backtraces in the future, but maybe somebody has an idea based on the described scenario. => maybe there is a race condition when the Phone sends OK messages for the NOTIFY messages after that the phone has already sent a BYE for the same call?



--
This message was sent by Atlassian JIRA
(v6.2#6252)