[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=234998#comment-234998 ] 

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

...though getprotobyname() failing doesn't make a huge amount of sense... the only reason I can see would be hitting FD limits (currently allowing 2048 and Asterisk is using around 150 or so in normal operation). I'll start logging FD use to look for hints of a leak.

> 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
>
> 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)