After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783543 - Async operation does not complete, resulting in sub-main-context iteration
Async operation does not complete, resulting in sub-main-context iteration
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Async
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2017-06-08 09:32 UTC by Christian Hergert
Modified: 2017-06-12 18:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Simple reproducer (278 bytes, text/plain)
2017-06-08 16:53 UTC, Rico Tzschichholz
  Details
codegen: Make the task_complete flag for <2.44 more similar to >=2.44 (5.39 KB, patch)
2017-06-12 16:08 UTC, Carlos Garnacho
none Details | Review
codegen: Make the task_complete flag for <2.44 more similar to >=2.44 (5.44 KB, patch)
2017-06-12 16:45 UTC, Carlos Garnacho
committed Details | Review

Description Christian Hergert 2017-06-08 09:32:24 UTC
Given this code:

 https://git.gnome.org/browse/gnome-builder/tree/plugins/vala-pack/ide-vala-index.vala#n151

		public async void add_files (ArrayList<GLib.File> files,
		                             GLib.Cancellable? cancellable)
		{
			Ide.ThreadPool.push (Ide.ThreadPoolKind.COMPILER, () => {
				lock (this.code_context) {
					Vala.CodeContext.push (this.code_context);
					foreach (var file in files)
						this.add_file (file);
					Vala.CodeContext.pop ();
					GLib.Idle.add(add_files.callback);
				}
			});

			yield;
		}

I'm seeing a poll() loop like this:

(gdb) bt
  • #0 poll
    from /lib64/libc.so.6
  • #1 g_poll
    at /home/christian/Projects/glib/glib/gpoll.c line 124
  • #2 g_main_context_poll
    at /home/christian/Projects/glib/glib/gmain.c line 4271
  • #3 g_main_context_iterate
    at /home/christian/Projects/glib/glib/gmain.c line 3967
  • #4 g_main_context_iteration
    at /home/christian/Projects/glib/glib/gmain.c line 4033
  • #5 ide_vala_index_add_files_co
    at /home/christian/Projects/gnome-builder-master/plugins/vala-pack/ide-vala-index.vala line 151
  • #6 _ide_vala_index_add_files_co_gsource_func
    at ide-vala-index.c line 990
  • #7 g_idle_dispatch
    at /home/christian/Projects/glib/glib/gmain.c line 5586
  • #8 g_main_dispatch
    at /home/christian/Projects/glib/glib/gmain.c line 3234
  • #9 g_main_context_dispatch
    at /home/christian/Projects/glib/glib/gmain.c line 3899
  • #10 g_main_context_iterate
    at /home/christian/Projects/glib/glib/gmain.c line 3972
  • #11 g_main_context_iteration
    at /home/christian/Projects/glib/glib/gmain.c line 4033
  • #12 g_application_run
    at /home/christian/Projects/glib/gio/gapplication.c line 2381
  • #13 main
    at ../src/main.c line 119

Which means I can't exit builder because it never returns to the main loop to exit when g_application_quit() is called.
Comment 1 Rico Tzschichholz 2017-06-08 16:06:20 UTC
Just to make sure. Did this work at some point, so is this a regression of vala?
Comment 2 Rico Tzschichholz 2017-06-08 16:49:46 UTC
Ok, this should be working for --target-glib=2.44

Therefore the compat-layer for glib 2.36-2.42 seems to be the culprit.

See https://git.gnome.org/browse/vala/commit/?id=a27219c5da0f622e148a3e6927a3ea8cefa337d8
Comment 3 Rico Tzschichholz 2017-06-08 16:53:36 UTC
Created attachment 353409 [details]
Simple reproducer

* Works with 0.34
* Works with 0.36 (without passing target-glib)
* Works while passing --target-glib=2.44
Comment 4 Christian Hergert 2017-06-08 20:38:42 UTC
Thanks for tracking this down!

For now, I just made Builder specify --target-glib=2.52.
Comment 5 Carlos Garnacho 2017-06-12 16:08:10 UTC
Created attachment 353606 [details] [review]
codegen: Make the task_complete flag for <2.44 more similar to >=2.44

According to the g_task_get_completed() docs (which we rely on for
glib >=2.44 targets): "This changes from FALSE to TRUE after the task's
callback is invoked, and will return FALSE from inside the callback".

So to make the code paths most similar to >= 2.44 (when
g_task_get_completed is available), wrap the GAsyncReadyCallback with
one of our own, that just invokes the nested callback (if any) and turns
on the flag.

Also remove the code turning on the flag on finish(), it's superfluous
now and there are no guarantees that it will be invoked.
Comment 6 Carlos Garnacho 2017-06-12 16:45:24 UTC
Created attachment 353607 [details] [review]
codegen: Make the task_complete flag for <2.44 more similar to >=2.44

According to the g_task_get_completed() docs (which we rely on for
glib >=2.44 targets): "This changes from FALSE to TRUE after the task's
callback is invoked, and will return FALSE from inside the callback".

So to make the code paths most similar to >= 2.44 (when
g_task_get_completed is available), wrap the GAsyncReadyCallback with
one of our own, that just invokes the nested callback (if any) and turns
on the flag.

Also remove the code turning on the flag on finish(), it's superfluous
now and there are no guarantees that it will be invoked.
Comment 7 Rico Tzschichholz 2017-06-12 18:57:04 UTC
commit be27b9e6d1b7cb590dcda6be6621d707887c87cb
Author: Carlos Garnacho <carlosg@gnome.org>
Date:   Mon Jun 12 17:19:05 2017 +0200

    codegen: Make the task_complete flag for < 2.44 more similar to >= 2.44