Gtk_drop_target_async_handle_event: assertion 'self->drop == drop' failed

Platform
1

On my port of xffm from gtk3 to gtk4 I already have drag and drop working just fine (apparently). But some times, when I drag from a gridview from one notebook tab to another, I some times a get a series of warnings as below. Apparently it happens when I have more than one droptarget controller in the application (maybe).

Since everything seems to work fine, should I be worried about the warnings? If so, does anyone know off hand what condition triggers the warning? I mean, how could self->drop != drop?

TIA for any pointers.

These are the flood of warnings:

(process:4144861): Gtk-CRITICAL **: 18:54:51.589: gtk_drop_target_async_handle_event: assertion 'self->drop == drop' failed
(process:4144861): Gtk-CRITICAL **: 18:54:51.593: gtk_drop_target_async_handle_event: assertion 'self->drop == drop' failed
(process:4144861): Gtk-CRITICAL **: 18:54:51.601: gtk_drop_target_async_handle_event: assertion 'self->drop == drop' failed
2

I mean, how could self->drop != drop?

FWIW, the relevant gtk4 code is gtk/gtkdroptargetasync.c#L205-257, where the assertion sanity check is in 2 places.

3

Thanks. I’ll see what I can make of it.

4

I figured it out.

Warning is triggered by a race condition between two or more threads handling drop targets asynchronously. In this circumstance, a critical warning is probably overkill, but there might be other conditions when the warning is indeed critical.

By why use asynchronous drop targets instead of synchronous?

The answer lies in the need for a drop target with GdkContentFormats. Synchronous drop targets are restricted to GTypes.

So, if you create several asynchronous drop targets, the race condition is bound to occur sometime or other.

The fix: use just one asynchronous drop target per application.

At first this solution seems to complicate things a bit, but in the end, not so.

5

Appears to be the following GTK issue:

6

Yes, it is the same thing. The drop still works because the function gtk_drop_target_async_handle_event does not send it further down, and it only refers to the drag-motion callback. The correct drag motion callback will be called in due course.

Since having more than one asynchronous drop target in the application will invariable lead to the warning (in non reproducible way) I would replace line 223 with

if (self->drop == drop) return FALSE;

otherwise document that good practice may involve a single asynchronous drop target per application.

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.