[asterisk-bugs] [JIRA] (ASTERISK-27170) memory corruption probably related to operations involved into PickupChan

[nappsoft (JIRA)]

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

nappsoft commented on ASTERISK-27170:
-------------------------------------

I've tested a bit with the patch applied and it seems to solve the issue. (This is still not a final conclusion as it could still be a coincidence... I did about 500 testcalls with pickup. Yes, I do have some other  hobbies ;) )

However it's more a hack than a clean solution as the memory management in this modified function is quite stupid considering the fact that pjsip works with memory pools wherever it's possible. However: stability matters more for me than overhead... Also I didn't check whether any function using pj_gethostbyname is relying on the error code, as h_error might contain wrong values in some race conditions. And last but not least it might be better to use getaddrinfo instead of gethostbyname_r. But this can do whoever has time to solve this in a clean way, I'm happy for the moment with my patch ;)

> memory corruption probably related to operations involved into PickupChan
> -------------------------------------------------------------------------
>
>                 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, 13.17.0
>         Environment: 64bit linux musl 1.1.16-git
>            Reporter: nappsoft
>            Assignee: Unassigned
>         Attachments: backtrace4.txt, crashlog.txt, gethostbyname_r.diff, trace_cel_crash.txt, trace.txt, valgrind2.txt, valgrind4.txt, vgcore.24994-brief.txt, vgcore.24994-full.txt, vgcore.24994-locks.txt, vgcore.24994-thread1.txt
>
>
> From time to time asterisk crashes when a component is trying to allocate memory. According to the sip traces this seem to happen mainly soon (sometimes some milliseconds, sometimes a few seconds) after a call in which a PickupChan operation was involved has been finished.



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