Search
Resolved
as Fixed Help for as Fixed

0
Sign in to vote
0
Sign in to vote
Sign in
 to vote
Type: Bug
ID: 489161
Opened: 9/10/2009 10:31:30 AM
Access Restriction: Public
1
Workaround(s)
0
User(s) can reproduce this bug
Scenario:
Client calls "ServiceA" which is a standard Singleton WCF service.

Inside of a service method ServiceA calls another WCF service, "ServiceB"

If the channel between "Service A" and "Service B" if faulted -> either by calling Channel.Abort in ServiceA or by faulting the channel in ServiceB, then there is a memory leak in ServiceA.
Details (expand)

Product Version

.NET Framework 3.5 SP1
Product Language
English

Operating System
Windows Server 2003
Operating System Language
English

Architecture
x86

Priority
(1=blocking, 2=important, 3=nice to have)
2

Severity
(1=major functionality issue, 2=important functionality issue, 3=nice to have)
2

Steps to Reproduce
From the description:
Client calls "ServiceA" which is a standard Singleton WCF service.
Inside of a service method ServiceA calls another WCF service, "ServiceB"
If the channel between "Service A" and "Service B" if faulted -> either by calling Channel.Abort in ServiceA or by faulting the channel in ServiceB, then there is a memory leak in ServiceA.
Actual Results
Channel resources are not freed, and a memory leak occurs.
Expected Results
resources should be freed appropriately.
Component Usage
(any information on your scenario that may help in investigating your issue)
This can be witnessed by using the SOS debugging to track behaviors on the ServiceA interface. Create a ContractBehavior that does nothing, and put it on the interface exposed by ServiceB. Then, after creating and aborting many channels between the services, you garbage collect and then search the heap for the ContractBehavior you created, and you will see that they are never collected. On channels where "Channel.Close" is called successfully before the channel is faulted, the resources are properly collected.
Lastly, if you use service instancing of "PerSession", and Concurrency of multiple (both together i believe), then the resources will always be cleaned up, so it appears that the resources remaining bound to a particular thread.
In our case, we saw memory grow out of control until the box fell over...It appears especially bad when you have large contracts because the xml datacontracts are held in memory without being released.

How often does this happen?
Always Happens

Have you seen this problem in other versions?
I don't know if this issue existed previously
File Attachments
1 attachments
Program.cs
Sign in to post a comment.
Posted by Microsoft on 9/10/2009 at 8:32 PM
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/)
Posted by Microsoft on 9/18/2009 at 10:21 AM
Jason,

Could you provide a code sample that produces the memory leak?

Andrew
Posted by Jason Burkey on 9/27/2009 at 8:26 AM
I've attached a quick program to display the problem...

There are 2 services - one that leaks and one that does not.

It makes 3 runs at the same service interface.

The first run calls the leaky service, but channels are closed properly -> no leaks are shown.
The second calls the leaky service, but channels are aborted -> leaks are displayed.
The third calls the non-leaky service and channels are aborted -> no leaks are shown.

Note that occasionally the third run will report leaks, this is because I didn't take the time to mess with the garbage collector. If you breakpoint, or stick some additional work before calling the GC then the channels get collected for the non-leaky case but NEVER for the leaky case. The results remain consistant under more stressful and longer running circumstances.
Posted by Fabrice Marguerie on 11/17/2009 at 2:29 AM
I can see that a file named Program.cs is attached, but I can't get it (no link, no way to download it). Is this normal?
How can I get the file?
© 2009 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement