Bug 28047 - Forms on separare threads -- Fatal errors/crashes
Summary: Forms on separare threads -- Fatal errors/crashes
Status: RESOLVED NOT_ON_ROADMAP
Alias: None
Product: Class Libraries
Classification: Mono
Component: Windows.Forms ()
Version: 3.12.0
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-03-15 19:43 UTC by ommymyca-6408
Modified: 2016-04-15 08:39 UTC (History)
6 users (show)

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


Attachments
screenshot of such an app running under MS .net framwork in wine. (123.74 KB, image/png)
2015-07-05 19:28 UTC, Hin-Tak Leung
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_ON_ROADMAP

Description ommymyca-6408 2015-03-15 19:43:03 UTC
Consider the following:

			for (int i = 0; i < 4; i++) {
				new Form ().Show ();
			}

vs

			Parallel.Invoke (delegate {
				new Form ().Show ();
			}, delegate {
				new Form ().Show ();
			}, delegate {
				new Form ().Show ();
			}, delegate {
				new Form ().Show ();
			});

Obviously, both are completely pointless by themselves; they're examples. In certain scenarios it could be necessary to create a form on a separate thread other than the main thread. For example, to create a modal popup to inform the user of a lengthy operation. No matter which approach I take, be it as a Backgroundworker, by Parallel.Invoke or by manually creating a Thread, I always end up with the same result -- crashes in either X11 or in Mono or in both. The example I posted results in

[xcb] Too much data requested from _XRead
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
mono: ../../src/xcb_io.c:736: _XRead: Assertion `!xcb_xlib_too_much_data_requested' failed.

Other examples will result in a Fatal IO error in X11: Resource temporarily unavailable and so forth. In the example I posted, I am not even closing the forms or accessing them individually in an unsafe manner, I am merely Invoking a few new forms and that already immediately causes the crash. I can aleviate some of the problems by slowing the creation down, for example, by sequentially creating the separate threads and adding Thread.Sleep calls to them to give the window manager time to catch up (or something). But, completely solving the issue I have as yet been unable to do.

Furthermore, randomly, intermittently, I will experience a different issue -- the form not actually being created at all, when creating one on a separate thread. To the point where it is not even a valid object, not even when accessing it in a threadsafe manner (by means of Invoke) -- "not set to an instance of an object".

So, my question is -- is it simply impossible to create a form on a separate thread or are we just looking at problems in the window manager here?

Ubuntu 14.10.1 running kernel version 3.19.1-low-latency and Mesa 10.6.
Comment 1 ommymyca-6408 2015-03-17 06:53:13 UTC
Another observation -- When approaching the issue in reverse, so performing the workload in the background and simply showing modal dialog in the main thread, some of the issues still persist.

Particularly, at times the modal dialog will simply be an invalid window, without handle, without contents. Completely locking the UI, as there is no object to Invoke a Close on. This phenomenon seems to occur when, over the course of the lifetime of the instance of the application, consecutive modal dialogs are required.
Comment 2 ommymyca-6408 2015-03-19 06:27:45 UTC
Further observation -- if I approach it from yet a different perspective, by making the form to be shown in a different thread a static form most of the issues seem to be resolved but the effect of the form being ghost-like (no contents, not even after manually Invalidating it) is more pronounced.
Comment 3 Zoltan Varga 2015-03-20 06:04:26 UTC
Is this a windows.forms problem ?
Comment 4 Rodrigo Kumpera 2015-04-02 14:16:15 UTC
This is a winforms issue.

I believe winforms is single threaded and the issue reported here is not a bug, it's just misuse of the API.
Comment 5 ommymyca-6408 2015-04-04 11:19:34 UTC
Misuse? Not so much. Abuse? Possibly. Either way, it matters very little, as whichever is the case, the result is the same -- there is no crossplatform, thread safe (or even unsafe), reliable way of doing what I aimed to accomplish.

Mind you, Fatal Errors in X11 tell me there is more going on than mere misuse or abuse of the winforms API. X is crashing, not Mono.
Comment 6 Hin-Tak Leung 2015-07-05 19:28:22 UTC
Created attachment 11864 [details]
screenshot of such an app running under MS .net framwork in wine.

This app runs happly under MS .net framwork in wine, and also under wine-mono in wine.
But can consistently crash linux mono, with say xcb message.

As you see it is quite sophisticated - it has a modal window showing progress, 
a help window; in the main window, it has a multiple document interface.

Since it work in .net and crash linux mono, I consider it a mono bug...

FWIW, it is a microsoft app, so you can't say it is abusing
https://www.microsoft.com/typography/FontValidator.mspx

If you want to see the crash, launch the app, 'add' any truetype font you have, then click 'start'.
Comment 7 Hin-Tak Leung 2015-07-05 19:32:04 UTC
I am on 4.0.2.5, BTW.
Comment 8 Rodrigo Kumpera 2015-07-06 11:31:33 UTC
This is a limitation of our winforms implementation and we're no longer actively maintaining it.

Though if you're interested in improving it we would love such contribution.
Comment 9 Hin-Tak Leung 2015-07-09 17:49:07 UTC
I did a further bit of web search, and found a work-around for the crash -
my X crash is due to https://bugzilla.novell.com/show_bug.cgi?id=436000 ,
and setting MONO_WINFORMS_XIM_STYLE=disabled do allow the application to proceed,
though it still does not work correctly (due to other issues), but at least it does not crash any more.

aapmak@gmail.com : can you give MONO_WINFORMS_XIM_STYLE=disabled a try?
BTW, also, complete small test code (rather than just snipplets) would be nice...
Comment 10 ommymyca-6408 2015-07-21 05:49:36 UTC
@Rodrigo: Thank you for clarifying that, it is as I suspected then.

@Hin-Tak Leung: A complete example would be kind of superfluous; it was an attempt to create modal auto-closing popups in my password manager. However, I have long since simply completely removed said functionality as there was no way to make it work. So, all I have is 'snippets'. I have spent quite some time on trying to solve the issue, but in the end I am left with concluding it is indeed a limitation in BOTH Mono as well as in X11 (which is just a dinosaur of a protocol). What I want to accomplish simply cannot be done in Mono, under Linux.
Comment 11 Hin-Tak Leung 2015-11-26 08:31:09 UTC
The font validator has gone open-sourced:
https://github.com/Microsoft/Font-Validator

and my rather substantial fork is at:
https://github.com/HinTak/Font-Validator

Yes, the threaded form updates probably falls into the pattern described. I have not looked further in that direction. But the source code probably serves as a complete and production example of such use.

(to be fair I experienced the crash with the 2003 version, which is a much older code base than this; I have not tried much to experience this problem with the current code - since a work-around exists which is harmless otherwise, I just use the workaround and get on with other matters)
Comment 12 Hin-Tak Leung 2015-11-26 08:33:27 UTC
One thing I like to look into is, besides 'disabled' in MONO_WINFORMS_XIM_STYLE=disabled , it takes others like on-the-spot, etc. does any of the others have impact on the bug.
Comment 13 waterfood128 2016-04-15 08:39:16 UTC
I have the same problem using Mono 4.0.4 on CentOS 7, where I call MessageBox.Show() from a background thread. The problem seems to be random - sometimes the dialog can show up correctly.

The workaround mentioned by @Hin-Tak Leung works on my machine.