Bug 2620 - [sgen] All objects don't seem to be freed
Summary: [sgen] All objects don't seem to be freed
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: General ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Rodrigo Kumpera
URL:
Depends on:
Blocks: 386
  Show dependency tree
 
Reported: 2011-12-22 19:05 UTC by Rolf Bjarne Kvinge [MSFT]
Modified: 2017-08-28 15:04 UTC (History)
4 users (show)

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

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:
RESOLVED FIXED

Description Rolf Bjarne Kvinge [MSFT] 2011-12-22 19:05:55 UTC
Test case: same as for #2619.

I've run it with the log profiler, and according to HeapShot (modified a bit to provide this info), there is a 42mb string and a 8mb byte array which are not referenced by any other object/root, and they're still not collected by the GC.

Applying the patch in comment #2 of #2619 is not required, but there will be other (huge) leaks without out (i.e. some noise).
Comment 1 Rolf Bjarne Kvinge [MSFT] 2012-01-04 15:55:33 UTC
Partially worked around in 72b8bf64.

The problem is that stacks are scanned conservatively, so any pointer pointing to an object (or the interior of an object) will keep that object alive. The bigger the object, the bigger the chance a pointer (or any other value that happens to look like a pointer) ends up keeping an object alive.

The above workaround makes all but 1 (or 2 once in a while) objects to go away for the test case, the remaining object is not freed because the number of seconds since Jan 1st, 1970 happens to look like a pointer to the interior of that object (i.e. bad luck in a call to mono_sem_timedwait, the timeout value happens to point into the object when considered as a pointer) [This was seen on linux x86]
Comment 2 Rolf Bjarne Kvinge [MSFT] 2012-01-17 11:47:23 UTC
The fix(es) for bug #2619 works for this one too (it's a variation of the same thing, conservative stack scanning). Not completely fixed, but enough to not leak for the provided test case