Bug 50763 - Stream.CopyTo leaks memory when using marksweep-conc
Summary: Stream.CopyTo leaks memory when using marksweep-conc
Status: VERIFIED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: GC ()
Version: 4.6.0 (C8)
Hardware: PC Linux
: --- normal
Target Milestone: 4.8.0 (C9)
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-12-23 22:08 UTC by Brandon White
Modified: 2017-01-13 10:44 UTC (History)
5 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Minimal reproducing test program. (2.72 KB, application/x-7z-compressed)
2016-12-23 22:12 UTC, Brandon White
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
VERIFIED FIXED

Description Brandon White 2016-12-23 22:08:40 UTC
The following leaks *native* heap memory when using marksweep-conc:

           while(true)
           {
                using (var outerStream = new System.IO.MemoryStream())
                {
                    using (var innerStream = new System.IO.MemoryStream())
                    {
                        for (int i = 0; i < 100; ++i)
                        {
                            innerStream.CopyTo(outerStream); 
                        }
                    }
                }
            }

If you periodically force a GC.Collect() you will still see the total process resident bytes rapidly increasing while the managed heap size is stable.

Mono JIT compiler version 4.6.2 (Stable 4.6.2.7/08fd525 Mon Nov 14 12:30:00 UTC 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen

I have also reproduced this on an armel system with 4.8.0:

Mono JIT compiler version 4.8.0 (Stable 4.8.0.344/f5fbc32 Fri Nov 18 13:04:32 UTC 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notifications: epoll
        Architecture:  armel,vfp+fallback
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen
Comment 1 Brandon White 2016-12-23 22:12:46 UTC
Created attachment 18985 [details]
Minimal reproducing test program.

Attached is a minimal reproducing program.  Execute using 

"MONO_GC_PARAMS=major=marksweep-conc mono CardEncodeLeak.exe"

Every 10 seconds it will output the managed heap size and the total process bytes.  Observe that the latter continually increases.
Comment 2 Brandon White 2016-12-23 22:14:10 UTC
I can confirm that running the test program without marksweep-conc (use default) does *not* manifest the leak.
Comment 3 Vlad Brezae 2016-12-24 01:40:34 UTC
Hello Brandon,

       This was actually fixed on master a while back. I'll make sure that the patch makes its way to 4.8 in time for the release. Thanks for the report.
Comment 4 Brandon White 2016-12-24 01:55:39 UTC
Thanks Vlad. At your convenience please post a link to the other bug report and/or the commit with the fix.
Comment 5 Brandon White 2016-12-24 17:24:51 UTC
Vlad, I found this PR which may be what you are referring to:

https://github.com/mono/mono/pull/3567

pertaining to https://bugzilla.xamarin.com/show_bug.cgi?id=41995
Comment 6 Vlad Brezae 2016-12-25 01:01:06 UTC
Yes. Commit [1] from that PR addresses this issue.

Also note from the other bug report, if you encountered this bug in a real world scenario, you might want to address the unusual number of Major Collections for performance reasons

[1] https://github.com/mono/mono/commit/86044c84c2222a984a473a4a1f572eb56fa8b5ab
Comment 7 Brandon White 2017-01-09 14:42:52 UTC
Hi Vlad, could you please merge this fix to the 4.8 branch soon?  We'd like to test this on our system.  Much appreciated!
Comment 8 Naqeeb 2017-01-12 11:37:29 UTC
Hi @vlad

I have checked this issue with latest master build i.e. MonoFramework-MDK-4.9.0.1456.macos10.xamarin.universal_b428249c7aace859020cc931b2a7f570e5c72ed9 and observed that it is working fine. Here is the screencast for the same: https://www.screencast.com/t/kBVFt5EgVNE

Please fix this issue with C9 build, so that I can verify on C9.

Thanks!
Comment 9 Naqeeb 2017-01-13 10:44:54 UTC
Hi @vladbrezae

I have checked this issue with latest C9 build i.e. MonoFramework-MDK-4.8.0.453.macos10.xamarin.universal and observed that it is working fine. Here is the screencast for the same: https://www.screencast.com/t/72lRhPQw9X

Hence closing this issue.

Thanks!