Question: thread safety and correct usage of mono_gc_reference_queue_* APIs when embedding Mono (rare crash)

[ffbh123456]

I’m embedding Mono and using the reference queue APIs to track when managed C# objects become unreachable so I can clean up associated native resources.

Specifically, I’m using:
mono_gc_reference_queue_new
mono_gc_reference_queue_add
mono_gc_reference_queue_free

I would like to know how to use these APIs when embedding Mono.
In my case, all three APIs are called directly from my main thread when needed and encounter below crash (rare).

thread_start
GC_start_routine
start_wrapper
start_wrapper_internal
finalizer_thread
reference_queue_process_all
malloc_report
malloc_vreport

malloc: *** error for object 0x600002ea4635:
pointer being freed was not allocated

[ffbh123456]

From what I see,
mono_gc_reference_queue_add does not appear to be thread-safe for direct calls from my main thread.

In my main thread, the call sequence is:
mono_gc_reference_queue_add → mono_gc_reference_queue_add_internal → ref_list_push

Meanwhile, the GC finalizer created by Mono itself runs in another thread with the following calls:
finalizer_thread → mono_runtime_do_background_work → reference_queue_process_all → reference_queue_process → ref_list_remove_element

In ref_list_remove_element, there is also a comment mentioning an issue when the head changes concurrently:
/* Guard if head is changed concurrently. */

[ffbh123456]

I’d like to implement this mechanism myself using the weak ref API. Could you confirm if these three APIs are safe to call from my main thread?

• mono_gchandle_new_weakref_v2
• mono_gchandle_get_target_v2
• mono_gchandle_free_v2