Bug 895 - Crash when freeing TimeoutInternalHandler
Summary: Crash when freeing TimeoutInternalHandler
Status: RESOLVED NOT_REPRODUCIBLE
Alias: None
Product: Gtk#
Classification: Mono
Component: gtk-sharp ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2011-09-19 08:40 UTC by Rolf Bjarne Kvinge [MSFT]
Modified: 2017-02-28 10:21 UTC (History)
3 users (show)

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


Attachments
t a a bt (20.08 KB, application/octet-stream)
2011-09-19 08:40 UTC, Rolf Bjarne Kvinge [MSFT]
Details


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 NOT_REPRODUCIBLE

Description Rolf Bjarne Kvinge [MSFT] 2011-09-19 08:40:22 UTC
Created attachment 421 [details]
t a a bt

Stack trace:

#0  0x9b6f89c6 in __pthread_kill ()
#1  0x967d0f78 in pthread_kill ()
#2  0x967c1bdd in abort ()
#3  0x00256c41 in monoeg_g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, format=0x275a68 "* Assertion at %s:%d, condition `%s' not met\n", args=0xb0182d94 "Ҟ'") at goutput.c:135
#4  0x00256ca3 in monoeg_assertion_message (format=0x275a68 "* Assertion at %s:%d, condition `%s' not met\n") at goutput.c:155
#5  0x0016ee39 in mono_delegate_free_ftnptr (delegate=0x93f3dc8) at marshal.c:516
#6  0x0014b541 in mono_gc_run_finalize (obj=0x93f3dc8, data=0x0) at gc.c:189
#7  0x00265ec0 in GC_invoke_finalizers () at finalize.c:787
#8  0x00119bc0 in mono_gc_invoke_finalizers () at boehm-gc.c:542
#9  0x0014d4ed in finalizer_thread (unused=0x0) at gc.c:1093
#10 0x001ff0f3 in start_wrapper_internal (data=0x1d8e4e0) at threads.c:783
#11 0x001ff193 in start_wrapper (data=0x1d8e4e0) at threads.c:831
#12 0x0023e366 in thread_start_routine (args=0x212f3b8) at wthreads.c:287
#13 0x0026f8bb in GC_start_routine (arg=0x457f60) at pthread_support.c:1468
#14 0x967ceed9 in _pthread_start ()
#15 0x967d26de in thread_start ()

(gdb) up 6
#6  0x0014b541 in mono_gc_run_finalize (obj=0x93f3dc8, data=0x0) at gc.c:189
189				mono_delegate_free_ftnptr ((MonoDelegate*)o);
(gdb) p ((MonoDelegate*) o).object.vtable->klass->name
$14 = 0x7d2c54 "TimeoutHandlerInternal"

This happens in MonoDevelop when editing widgets using the GUI editor. After adding/removing controls for a minute or so it invariably crashes.
Comment 1 Mike Kestner 2011-10-12 19:16:17 UTC
Did you really mean to open this against gtk#?  Seems like it's a bit lower on the stack than that to me.
Comment 2 Rolf Bjarne Kvinge [MSFT] 2011-10-14 05:18:13 UTC
Yeah, actually I did. My thought was that maybe gtk lets the delegate get collected too early by the gc.
Comment 3 Mike Kestner 2011-10-14 09:23:30 UTC
Rather unlikely.  There's even another bug open right now that contends we leak TimeoutProxy objects, which hold delegate refs.

Did you try running with keep-delegates?
Comment 4 Rolf Bjarne Kvinge [MSFT] 2011-10-17 08:52:20 UTC
I tried running both with gdb and keep-delegates, but then it didn't crash.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2017-02-28 10:21:03 UTC
I haven't seen this in years.