[asterisk-bugs] [JIRA] (ASTERISK-25170) Segfault in call to vsnprintf from astman_append

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton closed ASTERISK-25170.
-----------------------------------

    Resolution: Suspended

[~jrose] assisted me in triaging this issue since we don't have a way to reproduce. Jrose's analysis of the trace didn't find anything leading to a cause.

Unfortunately for further investigate we would require additional debug or a method of reproduction. I'll suspend the issue until we get further information as we don't have a way to pursue the issue.

Feel free to contact a bug marshal in #asterisk-bugs on irc.freenode.net when you have further information. At that point we can reopen the issue.

> Segfault in call to vsnprintf from astman_append
> ------------------------------------------------
>
>                 Key: ASTERISK-25170
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25170
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue, Core/ManagerInterface
>    Affects Versions: 11.17.0
>         Environment: VM debian 
> call-center 
>            Reporter: xavier Collet
>
> We had a segfault on an asterisk 11.17.0. Here's the backtrace of the thread which caused the segfault:
> {code}
> #0  0xb76b6da6 in _IO_default_xsputn () from /lib/i386-linux-gnu/libc.so.6
> #1  0xb7689b63 in vfprintf () from /lib/i386-linux-gnu/libc.so.6
> #2  0xb7731fc4 in __vsnprintf_chk () from /lib/i386-linux-gnu/libc.so.6
> #3  0x081f1b26 in vsnprintf (__ap=0xb1832618 "rݖ\264$\016k\262\344\fk\262\324\rk\262\067y\341\265\001", __fmt=0xb5e18e50 "Event: QueueMember\r\nQueue: %s\r\nName: %s\r\nLocation: %s\r\nStateInterface: %s\r\nMembership: %s\r\nPenalty: %d\r\nCallsTaken: %d\r\nLastCall: %d\r\nStatus: %d\r\nPaused: %d\r\nSkills: %s\r\n%s\r\n", __n=<optimized out>, __s=<optimized out>) at /usr/include/i386-linux-gnu/bits/stdio2.h:78
> #4  __ast_str_helper (buf=buf at entry=0xb18325ec, max_len=max_len at entry=0, append=append at entry=0, fmt=fmt at entry=0xb5e18e50 "Event: QueueMember\r\nQueue: %s\r\nName: %s\r\nLocation: %s\r\nStateInterface: %s\r\nMembership: %s\r\nPenalty: %d\r\nCallsTaken: %d\r\nLastCall: %d\r\nStatus: %d\r\nPaused: %d\r\nSkills: %s\r\n%s\r\n", ap=ap at entry=0xb1832618 "rݖ\264$\016k\262\344\fk\262\324\rk\262\067y\341\265\001") at strings.c:76
> #5  0x08172729 in ast_str_set_va (ap=0xb1832618 "rݖ\264$\016k\262\344\fk\262\324\rk\262\067y\341\265\001", fmt=0xb5e18e50 "Event: QueueMember\r\nQueue: %s\r\nName: %s\r\nLocation: %s\r\nStateInterface: %s\r\nMembership: %s\r\nPenalty: %d\r\nCallsTaken: %d\r\nLastCall: %d\r\nStatus: %d\r\nPaused: %d\r\nSkills: %s\r\n%s\r\n", max_len=0, buf=0xb18325ec) at asterisk-11.17.0/include/asterisk/strings.h:803
> #6  astman_append (s=s at entry=0xb1832cf8, fmt=fmt at entry=0xb5e18e50 "Event: QueueMember\r\nQueue: %s\r\nName: %s\r\nLocation: %s\r\nStateInterface: %s\r\nMembership: %s\r\nPenalty: %d\r\nCallsTaken: %d\r\nLastCall: %d\r\nStatus: %d\r\nPaused: %d\r\nSkills: %s\r\n%s\r\n") at manager.c:2268
> #7  0xb5df3a69 in manager_queues_status (s=0xb1832cf8, m=0xb1832af4) at app_queue.c:10027
> #8  0x0817b9d0 in process_message (s=s at entry=0xb1832cf8, m=m at entry=0xb1832af4) at manager.c:5284
> #9  0x0817eec9 in do_message (s=0xb1832cf8) at manager.c:5497
> #10 session_do (data=0xb4347a7c) at manager.c:5618
> #11 0x081f68e3 in handle_tcptls_connection (data=data at entry=0xb4347a7c) at tcptls.c:684
> #12 0x0820472f in dummy_start (data=0xb49fe0d0) at utils.c:1223
> #13 0xb720d954 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
> #14 0xb771ec8e in clone () from /lib/i386-linux-gnu/libc.so.6
> {code}
> The app_queue on this asterisk is slightly modified to add a "skill" attribute in the struct member, the attribute is an array, similar to the "interface" attribute.
> This is not a systematic problem, i.e. there's a lot of AMI "queue status" done on this asterisk and it segfaulted only one time. We don't know how to reproduce it.
> I have not included the whole backtrace since this happened on a production server and there is quite a lot of private information in it.
> Thank you 



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