[asterisk-bugs] [Asterisk 0016876]: setting pollmailboxes=yes will crash asterisk on startup
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Mar 8 10:56:15 CST 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=16876
======================================================================
Reported By: marcelloceschia
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 16876
Category: Applications/app_voicemail/ODBC
Reproducibility: have not tried
Severity: crash
Priority: normal
Status: feedback
Asterisk Version: 1.6.2.2
JIRA: SWP-944
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2010-02-21 10:41 CST
Last Modified: 2010-03-08 10:56 CST
======================================================================
Summary: setting pollmailboxes=yes will crash asterisk on
startup
Description:
Program terminated with signal 11, Segmentation fault.
https://issues.asterisk.org/view.php?id=0 0xb750d9a3 in strlen () from
/lib/libc.so.6
(gdb) bt full
https://issues.asterisk.org/view.php?id=0 0xb750d9a3 in strlen () from
/lib/libc.so.6
No symbol table info available.
https://issues.asterisk.org/view.php?id=1 0x08081947 in __ast_strdup (s=0x4
<Address 0x4 out of bounds>,
file=0xb67276e2 "app_voicemail.c", lineno=10274, func=0xb672c23a
"mwi_sub_event_cb") at astmm.c:261
len = 3076472820
ptr = <value optimized out>
https://issues.asterisk.org/view.php?id=2 0xb670a6ab in mwi_sub_event_cb
(event=0x909d5f0, userdata=0x0) at
app_voicemail.c:10274
__PRETTY_FUNCTION__ = "mwi_sub_event_cb"
https://issues.asterisk.org/view.php?id=3 0x080c79cf in handle_event
(data=0x909e0b8) at event.c:1137
ie_val = 0x0
sub = 0x8f9d4f0
https://issues.asterisk.org/view.php?id=4 0x0814ed04 in tps_processing_function
(data=0x82050a8) at
taskprocessor.c:310
t = 0x90b00b0
size = 0
__PRETTY_FUNCTION__ = "tps_processing_function"
https://issues.asterisk.org/view.php?id=5 0x0815b5c3 in dummy_start
(data=0x8209da8) at utils.c:968
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf =
{136355392, 0, 4001536, -1222401128, -490538338, -1896930336},
__mask_was_saved = 0}}, __pad = {0xb723a454, 0x0, 0xb7310ff4, 0x0}}
not_first_call = <value optimized out>
ret = <value optimized out>
__PRETTY_FUNCTION__ = "dummy_start"
https://issues.asterisk.org/view.php?id=6 0xb72ff6e5 in start_thread () from
/lib/libpthread.so.0
No symbol table info available.
https://issues.asterisk.org/view.php?id=7 0xb72ff600 in ?? () from
/lib/libpthread.so.0
No symbol table info available.
event->type = 768
event->event_len = 7680
event->payload = ""
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
child of 0015757 [branch] Add support for distributing d...
======================================================================
----------------------------------------------------------------------
(0119112) mmichelson (administrator) - 2010-03-08 10:56
https://issues.asterisk.org/view.php?id=16876#c119112
----------------------------------------------------------------------
Leif asked me to take a look at this, so let me weigh in.
I think the issue here is actually in the event code itself. Check out
frame 1 of both backtraces provided. The string being passed in is at
address 0x4. There is code in the ast_strdup function that makes sure that
if a NULL string is passed in, a NULL string is returned. Since the address
of the string is 0x4, we bypass that safeguard and attempt instead to read
the data. This address is clearly out of bounds, and thus there is a
crash.
The problem, if you ask me, is that for some reason
ast_event_get_ie_str(event, AST_EVENT_IE_MAILBOX) is not returning NULL
when it clearly should be. If it did, I suspect this crash would not occur.
The problem is either with the event itself, or that ast_event_get_ie_str
misbehaves when asked for an IE that is not in the event. My gut says it's
the former, but it would be a much better idea to test to determine the
fault instead of guessing.
Issue History
Date Modified Username Field Change
======================================================================
2010-03-08 10:56 mmichelson Note Added: 0119112
======================================================================
More information about the asterisk-bugs
mailing list