Summary:ASTERISK-14780: [patch] double free or corruption (!prev) in moh_files_generator
Reporter:Benny Amorsen (amorsen)Labels:
Date Opened:2009-09-07 04:10:08Date Closed:2009-10-07 13:38:25
Versions:Frequency of
Environment:Attachments:( 0) ast_devstate_aggregate_init-in-ast_extension_state2.patch
Description:Just a copy of 0015195. We don't even load asterisk-addons, so the proposed patch is a noop. Sorry I didn't respond earlier, but I have been on vacation.

It is rather silly that I cannot simply reopen the bug. "Older 1.6.0" is, all the information in bug 15195 still applies. We won't be able to run Asterisk under Valgrind in production.
Comments:By: Leif Madsen (lmadsen) 2009-09-08 11:17:09

Please test with latest 1.6.0 branch as changes for this issue have already been committed.

By: Benny Amorsen (amorsen) 2009-09-08 11:22:23

I would love to, but I only have the issue on production Asterisks, and bugs 15659 and 15852 prevent me from upgrading those. If you can tell me which svn revisions are likely to help fix, I will happily apply those to

By: Leif Madsen (lmadsen) 2009-09-08 13:30:11

The commit messages by svnbot in issue 15195 will tell you the revision numbers for the commits to the various branches.

By: Benny Amorsen (amorsen) 2009-09-08 13:51:02

r201612 didn't help, as I stated in bug 15195. The other patch is listed as "r1024", which sounds unlikely, but either way it applies to format_mp3.c, which is in Asterisk-addons. Asterisk-addons isn't on the systems which have problems.

By: Benny Amorsen (amorsen) 2009-09-29 07:00:56

I now have a crash from an Asterisk which didn't run music on hold. I cannot, of course, guarantee that the crash is the same issue, but it seems like it. Therefore the bug is probably not in res_musiconhold.

Valgrind will be put in use for the 3 of our Asterisks which are most often affected by this issue. Hopefully that will help.

By: Benny Amorsen (amorsen) 2009-10-07 05:09:13

It seems like this patch also prevents the following crash:

==27820== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==27820==  General Protection Fault
==27820==    at 0x4C26094: strcmp (mc_replace_strmem.c:337)
==27820==    by 0x9251CAB: local_devicestate (chan_local.c:150)
==27820==    by 0x453073: _ast_device_state (devicestate.c:331)
==27820==    by 0x453247: do_state_change (devicestate.c:439)
==27820==    by 0x453321: do_devstate_changes (devicestate.c:517)
==27820==    by 0x4CCFE7: dummy_start (utils.c:861)
==27820==    by 0x5B7A869: start_thread (in /lib64/libpthread-2.10.1.so)
==27820==    by 0x54DC39C: clone (in /lib64/libc-2.10.1.so)

(This was logged by valgrind on a server without the patch.)

By: Benny Amorsen (amorsen) 2009-10-07 13:12:49

Sorry, I meant the patch I will attach in a moment, which actually was intended to cure bug 15852.

By: Benny Amorsen (amorsen) 2009-10-07 13:16:02

Note that the idea for the patch came from wliegel. The patch simply does precisely as he suggested.

By: Digium Subversion (svnbot) 2009-10-07 13:38:22

Repository: asterisk
Revision: 222605

U   branches/1.6.0/main/pbx.c

r222605 | seanbright | 2009-10-07 13:38:21 -0500 (Wed, 07 Oct 2009) | 14 lines

Properly initialize ast_devstate_aggregate so we don't crash sporadically.

This looks like it was just missed during a merge.

(closes issue ASTERISK-14780)
Reported by: amorsen
     ast_devstate_aggregate_init-in-ast_extension_state2.patch uploaded by amorsen (license 676)
Tested by: amorsen

(closes issue ASTERISK-14792)
Reported by: amorsen
Tested by: amorsen, farisraouf