[asterisk-bugs] [JIRA] (ASTERISK-26759) Double free, ast_taskprocessor_execute->tps_task_free

[Stuart Henderson (JIRA)]

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

Stuart Henderson commented on ASTERISK-26759:
---------------------------------------------

Thanks Sean, that looks like an excellent candidate (and the right thing to do whether or not it fixes things for me) - I'll test over the next few days. There's another one in Skinny.

> Double free, ast_taskprocessor_execute->tps_task_free
> -----------------------------------------------------
>
>                 Key: ASTERISK-26759
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26759
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/General
>    Affects Versions: 13.13.1
>         Environment: OpenBSD 6.0, amd64. Using chan_sip, odbc realtime, http manager.
>            Reporter: Stuart Henderson
>            Assignee: Stuart Henderson
>         Attachments: 0001-http-getprotobyname-is-not-thread-safe.patch, ast_26759.debug.txt
>
>
> Asterisk had been up and operating normally for a week then exited with a malloc(3) detected "chunk is already free" error (OpenBSD malloc has double-free detection enabled all the time). I get the following backtrace - short bt inline, output from "thread apply all bt full" is at https://junkpile.org/ast13.13.1-20170130.txt.
> {noformat}
> (gdb) bt
> #0  0x00001f1890b581ca in thrkill () at <stdin>:2
> #1  0x00001f1890b3e499 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
> #2  0x00001f1890b82969 in wrterror (d=0x1f18437474d0, 
>     msg=0x1f1890c9980d "chunk is already free", p=0x1f181121f990)
>     at /usr/src/lib/libc/stdlib/malloc.c:295
> #3  0x00001f1890b82b3e in find_chunknum (d=0x1f18437474d0, r=<optimized out>, 
>     ptr=0x1f181121f990) at /usr/src/lib/libc/stdlib/malloc.c:1054
> #4  0x00001f1890b839b8 in free_bytes (ptr=<optimized out>, r=<optimized out>, 
>     d=<optimized out>) at /usr/src/lib/libc/stdlib/malloc.c:1072
> #5  ofree (pool=0x1f18437474d0, p=0x1f181121f990)
>     at /usr/src/lib/libc/stdlib/malloc.c:1337
> #6  0x00001f1890b83e3b in free (ptr=0x1f1862aae680)
>     at /usr/src/lib/libc/stdlib/malloc.c:1364
> #7  0x00001f15964a7209 in tps_task_free ()
> #8  0x00001f15964a72eb in ast_taskprocessor_execute ()
> #9  0x00001f15964af641 in worker_start ()
> #10 0x00001f15964b97c5 in dummy_start ()
> #11 0x00001f180e05e31e in _rthread_start (v=0x0)
>     at /usr/src/lib/librthread/rthread.c:115
> #12 0x00001f1890b0b75b in __tfork_thread ()
>     at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
> #13 0x0000000000000000 in ?? ()
> {noformat}
> The following lines were logged 2 seconds before the timestamp of the core, however they have been seen on one previous occasion not associated with a crash.
> {noformat}
> Jan 30 09:41:50 pbx7 asterisk[39270]: WARNING[-1]: http.c:1948 in httpd_helper_thread: Failed to set TCP_NODELAY on HTTP connection, getprotobyname("tcp") failed
> Jan 30 09:41:50 pbx7 asterisk[39270]: WARNING[-1]: http.c:1949 in httpd_helper_thread: Some HTTP requests may be slow to respond.
> {noformat}
> What other information would be useful? Is there anything I should capture in case it happens again? I have the core in case there's something you'd like me to poke at with gdb. Thanks.



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