Re: gio async usage from gtk+ ...

[Alexander Larsson <alexl redhat com>]

On Thu, 2011-03-24 at 12:53 +0000, Michael Meeks wrote:
> Hi guys,
> 
> 	I was just digging into a libreoffice assertion failure when using the
> gtk+ file selector:
> 
> Gtk:ERROR:gtkfilesystemmodel.c:746:gtk_file_system_model_sort: assertion
> failed: (r == n_visible_rows)
> 
> 	which looked to me, like it could well be a thread related issue; in
> particular since I'm browsing a 'busy' directory (ie. /tmp/ that my
> compilation is thrashing small files into and out of, no doubt creating
> thrash on the model too[1]).
> 
> 	I had a dig around in gtk/gtkfilesystemmodel.c on gtk-2-24 (I assume
> that is the last stable branch before 3.0), to see how threading is
> supposed to work; my trace is something like:
> 
> #2  0xb7c8c140 in abort () from /lib/libc.so.6
> #3  0xb401de52 in g_assertion_message (domain=0xb454df3b "Gtk", file=0xb45647f6 "gtkfilesystemmodel.c", line=746, func=0xb4564a84 "gtk_file_system_model_sort", 
>     message=<value optimized out>) at gtestutils.c:1358
> #4  0xb401e47f in g_assertion_message_expr (domain=0xb454df3b "Gtk", file=0xb45647f6 "gtkfilesystemmodel.c", line=746, func=0xb4564a84 "gtk_file_system_model_sort", expr=
>     0xb4564870 "r == n_visible_rows") at gtestutils.c:1369
> #5  0xb4342d8f in gtk_file_system_model_sort (model=<value optimized out>) at gtkfilesystemmodel.c:727
> #6  0xb4344b8e in _gtk_file_system_model_update_file (model=0x9981f48 [GtkFileSystemModel], file=0xae6918b0, info=0x90538b0, requires_resort=1) at gtkfilesystemmodel.c:1782
> #7  0xb4344cb0 in gtk_file_system_model_query_done (object=0xae6918b0 [GLocalFile], res=0x9168c38, data=0x9981f48) at gtkfilesystemmodel.c:1153
> #8  0xb3c15969 in g_simple_async_result_complete (simple=0x9168c38 [GSimpleAsyncResult]) at gsimpleasyncresult.c:747
> #9  0xb3c15a03 in complete_in_idle_cb_for_thread (_data=0x99c5af0) at gsimpleasyncresult.c:812
> #10 0xb3ff1e40 in g_idle_dispatch (source=0x9169518, callback=0xb3c159d0 <complete_in_idle_cb_for_thread>, user_data=0x99c5af0) at gmain.c:4536
> #11 0xb3ff64f9 in g_main_dispatch (context=0x8086d60) at gmain.c:2440
> #12 g_main_context_dispatch (context=0x8086d60) at gmain.c:3013
> #13 0xb3ff6d00 in g_main_context_iterate (context=0x8086d60, block=1, dispatch=1, self=0x80527a8) at gmain.c:3091
> #14 0xb3ff73df in g_main_loop_run (loop=0x998a130) at gmain.c:3299
> #15 0xb43074af in IA__gtk_dialog_run (dialog=0x96f1848 [GtkFileChooserDialog]) at gtkdialog.c:1094
> #16 0x8557e8d4 in ?? () from /usr/lib/libreoffice/program/../basis-link/program/fps_gnome.uno.so
> etc.
> 
> 	And I wonder where the GDK_THREADS_ENTER / GDK_THREADS_LEAVE that we
> need when entering from an idle handler is.
> 
> 	Presumably this is necessary for every '_async' callback that occurs
> [ and lets hope they are 100% called from the idle handler, and not
> sometimes for error conditions in-line ;-]. 

Yes, at least if the callback touches any gdk/gtk code.

There are (or should be) no direct callbacks from async calls, they
always go via an idle callback. Direct callbacks can cause all sorts of
other problems like destroy-before-using since apps don't expect
callbacks to run directly.

> 	And I was wondering: que ? there are ~24 of these '_async (' matches in
> gtk+, and of the few I spot-checked, none take the lock; feature or
> bug ?

Yeah, it does seem like a pretty bad bug. I'll have a look at fixing it.

> [1] - the file change handling FWIW is horribly inefficient, and once
> you have saved-as a /tmp file, life is really bad for your app (it goes
> away for long periods) for ever after if you start doing things actively
> in /tmp; at least for me of course ;-)

Not sure what you mean here? Do you mean while showing /tmp in the file
selector?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a sword-wielding flyboy rock star with a secret. She's a ditzy motormouth 
femme fatale from a secret island of warrior women. They fight crime!