Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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
Developer Community or GitHub 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.
The current code for GLib.ListBase ( https://gist.github.com/566f0cc9c8baf59e6327 ) and GLib.PtrArray appears to handle finalization incorrectly. While most Gtk objects add themselves to a finalization queue to be executed in the gtk main thread, these two classes directly process their destruction on the finalizer thread, including freeing their child elements.
Could this be the cause of this bug? This non-reproducable stacktrace from monodevelop makes it seem like gtk objects are been destroyed directly on the finalizer thread.
#0 0x9971cfda in __wait4 ()
#1 0x9ae664ec in waitpid$UNIX2003 ()
#2 0x0009fe9b in mono_handle_native_sigsegv (signal=11, ctx=0xb0182840) at mini-exceptions.c:2192
#3 0x00004f6e in mono_sigsegv_signal_handler (_dummy=11, info=0xb0182800, context=0xb0182840) at mini.c:5917
#4 <signal handler called>
#5 0x041839ea in emission_find ()
#6 0x0418a277 in signal_check_skip_emission ()
#7 0x0418a5cb in g_signal_emit_valist ()
#8 0x0418ae8e in g_signal_emit ()
#9 0x04175512 in g_object_dispatch_properties_changed ()
#10 0x04174014 in g_object_notify_dispatcher ()
#11 0x04175df6 in g_object_notify_queue_thaw ()
#12 0x04175896 in g_object_notify_by_spec_internal ()
#13 0x04175835 in g_object_notify ()
#14 0x0444ef80 in gtk_widget_hide ()
#15 0x04459386 in gtk_widget_dispose ()
#16 0x041755f4 in g_object_run_dispose ()
#17 0x04310b94 in gtk_object_destroy ()
#18 0x0cd769ec in ?? ()
#19 0x0cd76988 in ?? ()
#20 0x0cd7693c in ?? ()
#21 0x0cb10e82 in ?? ()
#22 0x0cb10e1f in ?? ()
#23 0x04defcc1 in ?? ()
#24 0x00129ee2 in mono_gc_run_finalize (obj=0x7c9d070, data=0x0) at gc.c:224
#25 0x0012a215 in finalizer_thread (unused=0x0) at gc.c:1024
#26 0x001bd8ec in start_wrapper (data=0x184f9d0) at threads.c:784
#27 0x001efa8a in thread_start_routine (args=0x2267bb8) at wthreads.c:287
#28 0x002171d4 in GC_start_routine (arg=0x502f60) at pthread_support.c:1468
#29 0x9aeb1ed9 in _pthread_start ()
#30 0x9aeb56de in thread_start ()
I don't see how those classes have anything to do with this trace? It looks like managed code called from some finalizer is calling Gtk.Widget.Destroy directly - but the finalizer could be on any class. Need to get method names for the managed frames.
Do you have any context for the trace?
I can only assume that i ran mono_pmip on stack frame 23->18 and found those classes in the stack trace.
Is my conclusion in comment 1 correct anyway? Regardless of whether or not they caused this particular issue, do we need the finalizers on these classes to proxy to the mainloop like everything else?
Not sure about the Free () or the GLib.Opaque.GetOpaque (NthData (i), element_type, true).Dispose () but the rest looks okay to me.
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?
If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.
Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.