Search

System.Speech has a memory leak by eoghanoh

Closed
as Won't Fix Help for as Won't Fix

8
0
Sign in
 to vote
Type: Bug
ID: 664196
Opened: 4/22/2011 9:01:47 AM
Access Restriction: Public
0
Workaround(s)
6
User(s) can reproduce this bug
Hi,

if you create a System.Speech.Synthesis.SpeechSynthesizer, and call the Speak method on it, for every time you call Speak, an object of type System.Speech.Internal.SPVTEXTFRAG is left in memory. This is bad because you can never get the memory back, not even by calling Dispose on the System.Speech.Synthesis.SpeechSynthesizer object. You can see that something has allocated a GCHandle to this instance and my guess is that it is no longer needed but the handle is never freed, hence the leak. That is bad enough as it causes a memory leak, but if this handle is pinned, the object will not be movable in memory and so may cause fragmentation. Eventually the app will crash with an out of memory exception.
Details (expand)

Visual Studio/Silverlight/Tooling version

.NET Framework 4

What category (if any) best represents this feedback?

Reliability

Steps to reproduce

Use this code. I originally had 1 synthesizer and just called speak on that over and over again and the exact same issue happened. Now I just use a synthesizer once and then dispose it and set it to null, and the object would go out of scope anyway outside the braces. But the error is still there, no matter which way you try it.
-------------------------------------------------

using System;
using System.Speech.AudioFormat;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Press RETURN to start");
            Console.ReadLine();
            string tts = "Hello. This is a test. I am testing something. Did the test work? We'll have to see.";
            SpeechAudioFormatInfo safi = new SpeechAudioFormatInfo(EncodingFormat.Pcm, 8000, 8, 1, 8000, 1, null);
            for (int i = 0; i < 100; i++)
            {
                System.Speech.Synthesis.SpeechSynthesizer ss = new System.Speech.Synthesis.SpeechSynthesizer();
                ss.Speak(tts);
                ss.Dispose();
                ss = null;
            }
            Console.WriteLine("Press RETURN");
            Console.ReadLine();
        }
    }
}

Product Language

English

Operating System

Windows 7

Operating System Language

English

Actual results

SPVTEXTFRAG objects left in memory - one for each time you called Speak

Expected results

No SPVTEXTFRAG objects left in memory
File Attachments
0 attachments
Sign in to post a comment.
Posted by Microsoft on 7/25/2012 at 9:56 PM
The WPF team has recently reviewed this issue and will not be addressing this issue as at this time the team is focusing on the bugs impacting the highest number of WPF developers. If you believe that this was resolved in error, please reactivate this bug with any necessary supporting details.
Posted by eoghanoh on 5/9/2011 at 8:40 AM
Hi,

is there any update on this?

It's not really feasible to use Microsoft.Speech as a workaround because of the issues detailed below.

Thanks,
Eoghan.
Posted by eoghanoh on 4/29/2011 at 2:34 AM
Hello,

I have tried the Microsoft.Speech namespace and it does not have the same issue. It behaves much better and does not leak. Thanks for the pointer on that. It is something we had looked at before with a view to writing in support, so I guess we'll just have to move that up the roadmap.

However, the main issue I can see with this is lack of voices. There are voices listed on your dowload page, but many of our customers would want to use SAPI voices which they have purchased. So what do I tell those customers?

Seeing as this bug is across all .NET versions and across all Windows operating systems, I have to say I'm kind of surprised that it still exists. Is there a timeline for Microsoft resolving this bug? It is obviously affecting people (just Bing it) and there are probably many more people who are being affected by it who do not realise it that SAPI might be the reason for their system crashing regularly or using more virtual memory than it needs to etc.

I don't imagine it would be a massive thing to resolve........

Thanks for your attention and help so far, it is very much appreciated.

Thanks,
Eoghan.

Posted by Microsoft on 4/27/2011 at 1:42 PM
>> When you say "Thanks. That helps isolate the problem.", does that mean you have found the issue?

Not 100% confirmed. But it looks really familiar.

As a possible work-around, there is also the Microsoft.Speech namespace, which you can download here:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=bb0f72cb-b86b-46d1-bf06-665895a313c7&displaylang=en
(see the bottom of that page for links to lang packs and the SDK). This shouldn't have the same issue. Let us know whether it's a viable workaround for you.
Posted by eoghanoh on 4/27/2011 at 6:32 AM
By the way, I reliase I had a typo in the original description: the object that is left in memory is System.Speech.Synthesis.TtsEngine.SPVTEXTFRAG, NOT System.Speech.Internal.SPVTEXTFRAG.

Sorry.

Everything else is correct.
Posted by eoghanoh on 4/27/2011 at 2:31 AM
Hi,

our product is a long running system which makes heavy use of SAPI. It's a runtime tool / framework for .NET developers and it's used by customers all around the world. The system needs to be up 24/7/365.

Memory grows and grows (we've tried this with just a simple console speech app) and gets fragmented and eventually it throws an OutOfMemoryException. Using .NET tools we have narrowed this down to the SPVTEXTFRAG object which is left in memory as a result of the call to Speak, held by a GCHandle. By the way we actually use SpeakAsync but the issue is the same.

We can't even recommend to a customer to use a different version of windows or a different version of .NET as this appears to be unrelated to the operating system / .NET version. We have found this issue across multiple O/S's and .NET frameworks (from 3.0 onwards which includes speech), including the very latest of both including all updates.

If you look at this:

http://www.bing.com/search?q=system.speech+memory+leak&go=&form=QBLH&filt=all&qs=n&sk=&sc=1-25

it seems I am not the only one having issues with memory leaks in SAPI (although some of these may be false and some may be a different leak to the one I'm experiencing).

It's a very serious issue for us as it affects not only our product but products that our customers have written based on our product. And it's not just an annoyance or a small bug, it means a complete system down because it crashes when the number of SPVTEXTFRAG objects get sufficiently high.

When you say "Thanks. That helps isolate the problem.", does that mean you have found the issue?

Thanks,
Eoghan.
Posted by Microsoft on 4/26/2011 at 4:17 PM
Thanks. That helps isolate the problem.

Can you give us some feedback on how seriously this is affecting your application?
Posted by eoghanoh on 4/26/2011 at 8:19 AM
I have done this and uploaded the file.

It gets an out of memory exception, then I create the dump.

Now, just to be clear, the out of memory exception occurs earlier than it would naturally because I am synthesizing all of the output to a stream, and the stream grows massively. I just did this to cause a crash quickly. So don't come back to me and say it ran out of memory because the stream got too big! That's not really the issue here. What I want you to see is that there are SPVTextFrag entries left in memory and there should not be. There's 1 for each Speak call. These obejcts have GCHandles assigned to them, and they cause fragmentation in memory over time. There should not be any SPVTEXTFRAG objects left in memory after the call to speak, and certainly not after I call dispose on the synthesizer.
Posted by Microsoft on 4/25/2011 at 2:06 AM
Thanks for reporting the issue.
In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

It may help if you provide us with a mini dump file and call stack. You can use the following steps to get a mini dump file:
1. Start Visual Studio.
2. Start another instance of VS.
3. In the second instance click Tools | Attach to Process...
4. In the list of processes locate devenv.exe.
5. Click Select... and explicitly choose 'Native' and 'Managed' code.
6. Click OK and OK to close Select dialog and Attach to Process dialog.
7. Go back to the first instance of VS and repro the crash.
8. Upon the crash, control should go to the second instance of VS.
9. In the second instance click Debug | Save Mini Dump (without heap).

If you are running the VB profile you will not see the Save Dump As menu item. To add this menu item:
a. Select Tools -> Customize
b. Select the Commands tab
c. Select Debug from the Menu bar dropdown
d. Click Add Command...
e. Select Debug from the Categories list.
f. Find the Save Dump As entry in the Commands window.
g. Click OK (the Save Dump As... command is added to the top of the Debug menu).
h. Click Close

You can get detailed steps about how to get the dump file and call stack at http://blogs.msdn.com/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx

Please package your file into a zip file and name the zipped file Feedback-664196.zip.
You can upload the file to workspace:

https://sftasia.one.microsoft.com/choosetransfer.aspx?key=7c8336de-83fb-4481-96e0-d7f7f88e35d4
Password: F^p#w)54n)*d)

It would be greatly appreciated if you could provide us with that information as quickly as possible.

Thanks again for your efforts and we look forward to hearing from you.
Posted by Microsoft on 4/22/2011 at 9:13 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
© 2013 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement