[mono] call GC.Collect(); block the main thread won't resume

[srxqds]

Description

i am embedding the monovm with ue.
i call GC.Collection will block the main thread.

Reproduction Steps

our code is simple:

// call from native use mono_runtime_invoke
public void Unload(IPlugin plugin)
{
    plugin.Clear();  // do some clear work
    GC.Collect();
    plugin.Unload();
}

this is the thread call stack:

Expected behavior

no block

Actual behavior

work correctly

Regression?

No response

Known Workarounds

No response

Configuration

build latest release/6.0
windows x64

Other information

No response

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[gfoidl]

i call GC.Collection will block the main thread.

It's documentated that way, to do a blocking collection. Do you aim for a background collection? If so see docs on how to call the method to perform a background GC.

[srxqds]

ou aim for a backgroun

no, it is always block, not resume.

and the monovm support background gc?

@gfoidl

[gfoidl]

and the monovm support background gc?

Let's have a look into the docs for GC.Collect 😉

[srxqds]

ok, thanks, but it is not resumed after gc?

[srxqds]

and other thread call stack:

Tagging subscribers to this area: @BrzVlad
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

i am embedding the monovm with ue.
i call GC.Collection will block the main thread.

Reproduction Steps

this is the thread call stack:

Expected behavior

no block

Actual behavior

work correctly

Regression?

No response

Known Workarounds

No response

Configuration

build latest release/6.0
windows x64

Other information

No response

Author:	srxqds
Assignees:	-
Labels:	untriaged, area-GC-mono
Milestone:	-

[srxqds]

@lateralusX @lambdageek @vargaz @BrzVlad I am sorry for always ping you, can you help me figure out why made this block?

[vargaz]

The GC needs to wait for all the threads in the app to suspend, which doesn't happen here for some reason. Maybe there is a thread registered with the runtime which is blocking in some way.
Also note that the mono GC is conservative, which means that calling GC.Collect () is not guaranteed to collect all dead objects, so it might not achieve what you want it to achieve.

[srxqds]

Also note that the mono GC is conservative, which means that calling GC.Collect () is not guaranteed to collect all dead objects, so it might not achieve what you want it to achieve.

ok, but in what situation, dead objects will not collect immediately?

[lambdageek]

@srxqds There's probably a deadlock with some other thread. hmm.. wait_for_attach requires GC Safe mode, but I'm not sure that debugger_thread is in GC Safe mode - I think it starts in GC Unsafe mode.

What is probably happening is because it's in GC Unsafe mode (ie cooperative suspension mode), the main collector thread is probably waiting for it to suspend.

You can try setting the environment variable MONO_SLEEP_ABORT_LIMIT to some number like 2000 (2 seconds). It will try to suspend the threads and if it doesn't work in 2 seconds, it will cause the app to abort and dump the thread states to stdout.

[srxqds]

@srxqds There's probably a deadlock with some other thread. hmm.. wait_for_attach requires GC Safe mode, but I'm not sure that debugger_thread is in GC Safe mode - I think it starts in GC Unsafe mode.

What is probably happening is because it's in GC Unsafe mode (ie cooperative suspension mode), the main collector thread is probably waiting for it to suspend.

You can try setting the environment variable MONO_SLEEP_ABORT_LIMIT to some number like 2000 (2 seconds). It will try to suspend the threads and if it doesn't work in 2 seconds, it will cause the app to abort and dump the thread states to stdout.

I use --debugger-agent=transport=dt_socket,embedding=1,suspend=n,server=y,address=127.0.0.1:9000 deubg options

this is because mono_thread_create change to gc unsafe state?