# Memory Leak Solved With Sync (no way)

**URL:** <https://www.ruby-forum.com/t/memory-leak-solved-with-sync-no-way/66457>\
**Category:** Ruby\
**Created:** [August 26, 2006, 10:53am UTC](https://www.ruby-forum.com/t/memory-leak-solved-with-sync-no-way/66457 "2006-08-26T10:53:49Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Zed\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/da6949/32.png) [@Zed\_S](https://www.ruby-forum.com/u/Zed_S)\
**Post date:** [August 26, 2006, 10:53am UTC](https://www.ruby-forum.com/t/memory-leak-solved-with-sync-no-way/66457/1 "2006-08-26T10:53:49Z")

</div>

So I recently posted that there’s a memory leak in the below script:

[http://pastie.caboo.se/10194](http://pastie.caboo.se/10194)

With graphs and all. The general response was the following:

1. That’s just how the OS accounts for memory (wrong since the processes  
were getting killed for using too much ram, and the OS doesn’t keep 100m  
around over 10 minutes of slow ram cycling).
2. That’s fixed in ruby 1.8.5 (wrong again as we tested it in 1.8.5 and  
actually had worse results).
3. It must be written wrong (yet not many suggestions on how to rewrite  
it).
4. Don’t use Mutex.lock/Mutex.unlock but instead use Mutex.synchronize  
{ } (wrong, doing this reduced the total ram for some, not for others  
and still lead to an overall increasing trend).

Bradley Taylor and I investigated it further today and he found that  
Sync does not have this leak. Here’s the evidence for it:

[http://pastie.caboo.se/10317](http://pastie.caboo.se/10317)

As you can see this is nearly the same code but instead of Mutex we use:

@guard.synchronize(:EX) {  
}

And make @guard a Sync object. From the graph you can see the GC  
working _properly_.

I just want to say that this is how ram is supposed to operate with a  
GC. If you see memory that increases to a level and doesn’t go down  
then you’ve got a leak.

Also, I managed to reduce this bug down to the initial test script in  
about an hour. That helped tremendously in finding the problem and the  
solution. I suggest everyone take this approach with complex bugs as  
well since a simple yet unrealistic case that demonstrates the bug is  
easier to deal with.

Hopefully I’ll get this change into Mongrel and it’ll fix the memory  
leak. Thanks for everyone’s help and suggestions.