Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Locking finalizer keeping app alive #314

Closed
adamsitnik opened this issue Nov 26, 2019 · 2 comments · Fixed by #38909
Closed

Locking finalizer keeping app alive #314

adamsitnik opened this issue Nov 26, 2019 · 2 comments · Fixed by #38909

Comments

@adamsitnik
Copy link
Member

adamsitnik commented Nov 26, 2019

While working on dotnet/performance#1049 I've found that following app never quits:

using System;
using System.Collections.Concurrent;
using System.Threading;

namespace Neverending
{
    class Program
    {
        static void Main()
        {
            new Thread(() =>
            {
                while(true)
                {
                    GC.KeepAlive(new ConcurrentBag<string>());
                }
            }).Start();

            Console.WriteLine("Going to sleep");

            Thread.Sleep(TimeSpan.FromSeconds(3));

            Console.WriteLine("Woke up!");
        }
    }
}

obraz

@stephentoub is this expected behavior?

edit: simpler repo

@stephentoub
Copy link
Member

stephentoub commented Nov 26, 2019

This isn't specific to ConcurrentBag. The same pattern it employs with a finalizer that locks has the same behavior:

using System;
using System.Threading;

class Program
{
    static void Main()
    {
        new Thread(() => { while (true) GC.KeepAlive(new Finalizable()); }) { IsBackground = true }.Start();
        Console.WriteLine("Going to sleep");
        Thread.Sleep(TimeSpan.FromSeconds(3));
        Console.WriteLine("Woke up!");
    }
}

class Finalizable
{
    private static readonly object s_lock = new object();

    ~Finalizable()
    {
        lock (s_lock) { }
    }
}

@stephentoub stephentoub changed the title Suprising side effect of Concurrent Bag ctor Locking finalizer keeping app alive Nov 27, 2019
AndyAyersMS added a commit to AndyAyersMS/runtime that referenced this issue Jan 15, 2020
Make STRESS_GENERIC_VARN more compatible with methods that make explicit tail
calls. Don't add gc checks for explicit tail calls, and remove the code in
morph that blocks tail calls if gc checks are active.

Update the tailcall test to to disable STRESS_UNSAFE_BUFFER_CHECKS. This can
be reverted when dotnet#314 is merged.

Fixes dotnet#1752.
@joperezr joperezr added bug and removed untriaged New issue has not been triaged by the area owner labels Jul 7, 2020
@joperezr joperezr added this to the Future milestone Jul 7, 2020
@joperezr
Copy link
Member

joperezr commented Jul 7, 2020

I assume this is not a regression so I have set milestone to future. Feel free to pull it back to 5.0 otherwise.

jkotas added a commit to jkotas/runtime that referenced this issue Jul 8, 2020
The finalization queue can be long or constantly growing when the finalization thread is not able to
keep up with finalizable object allocation rate. This can lead to shutdown being blocked for a long
time or indefinitely.

The fix is stop the finalization loop once we enter shutdown instead of trying to empty the finalization
queue.

Fixes dotnet#314
jkotas added a commit that referenced this issue Jul 8, 2020
The finalization queue can be long or constantly growing when the finalization thread is not able to
keep up with finalizable object allocation rate. This can lead to shutdown being blocked for a long
time or indefinitely.

The fix is stop the finalization loop once we enter shutdown instead of trying to empty the finalization
queue.

Fixes #314
@adamsitnik adamsitnik modified the milestones: Future, 5.0.0 Jul 8, 2020
adamsitnik added a commit to dotnet/BenchmarkDotNet that referenced this issue Oct 23, 2020
so we need to dispose them after we are done running the benchmarks

see #1383 and dotnet/runtime#314 for more
AndreyAkinshin pushed a commit to dotnet/BenchmarkDotNet that referenced this issue Oct 26, 2020
…nting the results (#1571)

* add test

* dispose unused dispsable parameters

* stop the benchmark process output stream processing after receiving the last signal

* don't try to read the standard error as it might also hang

the benchmark process is catching all exceptions and writing to standard output, so it's OK (this is what the class Executor does already)

* kill benchmarking process if it does not quit within 250ms after finishing benchmarking

* exit code can be != 0 for benchmarks that have executed fine but hanged after printing the results

* some benchmarks might be using parameters that have locking finalizers

so we need to dispose them after we are done running the benchmarks

see #1383 and dotnet/runtime#314 for more
MichalStrehovsky pushed a commit to MichalStrehovsky/runtime that referenced this issue Nov 10, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants