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 617611 - redo_queries calls gtk+ functions in non-main thread
redo_queries calls gtk+ functions in non-main thread
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
2.32.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
: 626641 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-05-04 06:18 UTC by Ruchir Brahmbhatt
Modified: 2010-10-21 10:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
evo patch (2.55 KB, patch)
2010-10-13 07:40 UTC, Milan Crha
committed Details | Review

Description Ruchir Brahmbhatt 2010-05-04 06:18:35 UTC
OS: opensuse 11.2
Evolution: 2.30.1
Account: Gmail IMAP
Calendar backend: Google calendar

Steps to reproduce:
1. Open evolution.
2. Go to calendar.
3. Click previous or next day button.

Backtrace:


Comment 1 Akhil Laddha 2010-05-04 07:10:37 UTC
Thanks for taking the time to report this bug.
Unfortunately, that stack trace is missing some elements that will help a lot
to solve the problem, so it will be hard for the developers to fix that crash.
Could you please install some debugging packages [1], start the application as
normal, and reproduce the crash, if possible?

Once bug-buddy pops up, you can find the stacktrace in the Details, now
containing way more information. Please copy that stacktrace and paste it as a
comment here. Thanks in advance!

[1] debugging packages for evolution, evolution-data-server, evolution-exchange, gtkhtml2, gtk2 and glib2 (as far as those packages are provided by your distribution). More details can be found here:
http://live.gnome.org/GettingTraces
Comment 2 Ruchir Brahmbhatt 2010-05-04 07:25:46 UTC
Here is the backtrace after installing debuginfo packages for evo, eds, gtkhtml2, gtk2 & glib2.


Comment 3 Akhil Laddha 2010-05-04 08:18:11 UTC
Trace doesn't look useful :-(
Are you sure that you have same debuginfo rpm version as package ?

Btw if you run evolution under gdb, please don't forget to paste crash point (3-4 line before you do 'thread apply all bt'). Other wise it's difficult to identify in which thread application has crashed.
Comment 4 André Klapper 2010-05-04 18:27:27 UTC
Trace does not show any debug symbols. Package version mismatches?
Comment 5 Ruchir Brahmbhatt 2010-05-05 06:34:35 UTC
Yes somehow different version debuginfo packages were installed. I corrected it and collected below bt.

0x00007fd23271bd03 in poll () from /lib64/libc.so.6
(gdb) t a a bt


Comment 6 Milan Crha 2010-10-01 08:10:42 UTC
Thanks for a bug report. I'm slightly confused, because the trace doesn't indicate any crash, every thread is "polling" there, though the first one in X. I partially recall I was fixing something similar in calendar, bug I do not recall when exactly.

Could you try with either 2.30.3 or the best with just released 2.32.0, please?
Comment 7 Ruchir Brahmbhatt 2010-10-01 12:31:03 UTC
This disappeared in 2.30.x but now I switched to 2.23.0 and I can reproduce again. I get following in GDB.


The program 'evolution' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 13471 error_code 2 request_code 149 minor_code 5)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[Thread 0x7fffd9e83710 (LWP 16030) exited]
[Thread 0x7fffd8a10710 (LWP 16033) exited]
[Thread 0x7fffdb686710 (LWP 16026) exited]
[Thread 0x7fffdc2c7710 (LWP 16025) exited]
[Thread 0x7fffdcac8710 (LWP 16023) exited]
[Thread 0x7fffe29c2710 (LWP 16022) exited]
[Thread 0x7fffeae03710 (LWP 16020) exited]

Program exited with code 01.
Comment 8 Ruchir Brahmbhatt 2010-10-01 12:33:01 UTC
Sorry for multiple mails, I forgot to change status first and now changing version also.
Comment 9 Milan Crha 2010-10-01 14:27:16 UTC
Thanks for the update. The backtrace from comment #8 doesn't seem to get it in, but reading the comments

> (Note to programmers: normally, X errors are reported asynchronously;
>  that is, you will receive the error a while after causing it.
>  To debug your program, run it with the --sync command line
>  option to change this behavior. You can then get a meaningful
>  backtrace from your debugger if you break on the gdk_x_error() function.)

I would like to ask you to follow that advice. If I got it right then it might do the thing when you run evolution from console under gdb like this:
   $ gdb evolution --ex "b gdk_x_error" --ex "r --sync" --ex "t a a bt" --ex q
Only note that it'll ask you whether you want to add a pending breakpoint, where you should answer 'y' (the default is 'no').
Comment 10 Ruchir Brahmbhatt 2010-10-02 06:01:18 UTC
Tried those steps and got following.


evolution: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
The program 'evolution' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadGC (invalid GC parameter)'.
  (Details: serial 18001 error_code 13 request_code 60 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[Thread 0x7fffdb686710 (LWP 10208) exited]
[Thread 0x7fffd8a10710 (LWP 10215) exited]
[Thread 0x7fffd9e83710 (LWP 10212) exited]
[Thread 0x7fffdc2c7710 (LWP 10207) exited]
[Thread 0x7fffdcac8710 (LWP 10205) exited]
[Thread 0x7fffe29c2710 (LWP 10204) exited]
[Thread 0x7fffeae03710 (LWP 10202) exited]

Program exited with code 01.
Comment 11 Milan Crha 2010-10-04 08:01:51 UTC
Strange, it's pretty same as comment #10. It seems it didn't stop on the gdk_x_error function.
Comment 12 Ruchir Brahmbhatt 2010-10-04 09:28:04 UTC
Yeah, any other things to try?
Comment 13 Milan Crha 2010-10-04 10:12:57 UTC
None I would be 100% sure of the functionality, sadly. Maybe try the above command in steps, like:
   $ gdb evolution --ex "r --sync"
when evolution is loaded, go to the terminal where you invoked the gdb and do these:
   Ctrl+C
   (gdb) b gdk_x_error
now it should tell you it added a breakpoint to that function, indicating the line number and source file
   (gdb) c
let it crash now, and if it stops in that function, then run:
   (gdb) t a a bt
to obtain the backtrace of all currently running threads.

Maybe try to catch me on irc.gimp.org #evolution, if the above will not work.
Comment 14 Ruchir Brahmbhatt 2010-10-04 12:55:41 UTC
(gdb) t a a bt

Thread 18 (Thread 0x7fffd895e710 (LWP 17357))

  • #0 std::basic_ostream<wchar_t, std::char_traits<wchar_t> >::flush()
    from /usr/lib64/libstdc++.so.6
  • #1 std::ios_base::Init::~Init()
    from /usr/lib64/libstdc++.so.6
  • #2 __run_exit_handlers
    from /lib64/libc.so.6
  • #3 exit
    from /lib64/libc.so.6
  • #4 gdk_x_io_error
    at gdkmain-x11.c line 524
  • #5 _XIOError
    from /usr/lib64/libX11.so.6
  • #6 _XReply
    from /usr/lib64/libX11.so.6
  • #7 XSync
    from /usr/lib64/libX11.so.6
  • #8 ??
    from /usr/lib64/libX11.so.6
  • #9 XFreeGC
    from /usr/lib64/libX11.so.6
  • #10 gdk_gc_x11_finalize
    at gdkgc-x11.c line 84
  • #11 g_object_unref
    from /usr/lib64/libgobject-2.0.so.0
  • #12 cell_toggle_unrealize
    at e-cell-toggle.c line 187
  • #13 eti_unrealize_cell_views
    at e-table-item.c line 411
  • #14 eti_remove_header_model
    at e-table-item.c line 604
  • #15 eti_dispose
    at e-table-item.c line 1421
  • #16 g_object_run_dispose
    from /usr/lib64/libgobject-2.0.so.0
  • #17 etgl_dispose
    at e-table-group-leaf.c line 100
  • #18 g_object_run_dispose
    from /usr/lib64/libgobject-2.0.so.0
  • #19 e_table_group_container_child_node_free
    at e-table-group-container.c line 75
  • #20 etgc_remove
    at e-table-group-container.c line 603
  • #21 et_table_rows_deleted
    at e-table.c line 967
  • #22 g_closure_invoke
    from /usr/lib64/libgobject-2.0.so.0
  • #23 ??
    from /usr/lib64/libgobject-2.0.so.0
  • #24 g_signal_emit_valist
    from /usr/lib64/libgobject-2.0.so.0
  • #25 g_signal_emit
    from /usr/lib64/libgobject-2.0.so.0
  • #26 redo_queries
    at e-cal-model.c line 2364
  • #27 update_todo_view_async
    at gnome-cal.c line 1270
  • #28 message_proxy
    at gnome-cal.c line 187
  • #29 g_thread_pool_thread_proxy
    at gthreadpool.c line 319
  • #30 g_thread_create_proxy
    at gthread.c line 1897
  • #31 start_thread
    from /lib64/libpthread.so.0
  • #32 clone
    from /lib64/libc.so.6
  • #33 ??

Thread 1 (Thread 0x7ffff7fb6940 (LWP 17330))

  • #0 gdk_x_error
    at gdkmain-x11.c line 438
  • #1 _XError
    from /usr/lib64/libX11.so.6
  • #2 ??
    from /usr/lib64/libX11.so.6
  • #3 _XReply
    from /usr/lib64/libX11.so.6
  • #4 XSync
    from /usr/lib64/libX11.so.6
  • #5 ??
    from /usr/lib64/libX11.so.6
  • #6 ??
    from /usr/lib64/libcairo.so.2
  • #7 ??
    from /usr/lib64/libcairo.so.2
  • #8 ??
    from /usr/lib64/libcairo.so.2
  • #9 ??
    from /usr/lib64/libcairo.so.2
  • #10 ??
    from /usr/lib64/libcairo.so.2
  • #11 ??
    from /usr/lib64/libcairo.so.2
  • #12 ??
    from /usr/lib64/libcairo.so.2
  • #13 cairo_fill_preserve
    from /usr/lib64/libcairo.so.2
  • #14 cairo_fill
    from /usr/lib64/libcairo.so.2
  • #15 day_view_main_item_draw
    at e-day-view-main-item.c line 1087
  • #16 gnome_canvas_group_draw
    at gnome-canvas.c line 1715
  • #17 gnome_canvas_paint_rect
    at gnome-canvas.c line 3110
  • #18 gnome_canvas_expose
    at gnome-canvas.c line 3170
  • #19 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 86
  • #20 g_closure_invoke
    from /usr/lib64/libgobject-2.0.so.0
  • #21 ??
    from /usr/lib64/libgobject-2.0.so.0
  • #22 g_signal_emit_valist
    from /usr/lib64/libgobject-2.0.so.0
  • #23 g_signal_emit
    from /usr/lib64/libgobject-2.0.so.0
  • #24 gtk_widget_event_internal
    at gtkwidget.c line 4977
  • #25 IA__gtk_main_do_event
    at gtkmain.c line 1601
  • #26 _gdk_window_process_updates_recurse
    at gdkwindow.c line 5424
  • #27 _gdk_window_process_updates_recurse
    at gdkwindow.c line 5397
  • #28 _gdk_window_process_updates_recurse
    at gdkwindow.c line 5397
  • #29 gdk_window_process_updates_internal
    at gdkwindow.c line 5583
  • #30 IA__gdk_window_process_all_updates
    at gdkwindow.c line 5691
  • #31 gtk_container_idle_sizer
    at gtkcontainer.c line 1359
  • #32 gdk_threads_dispatch
    at gdk.c line 512
  • #33 g_main_dispatch
    at gmain.c line 2149
  • #34 g_main_context_dispatch
    at gmain.c line 2702
  • #35 g_main_context_iterate
    at gmain.c line 2780
  • #36 g_main_loop_run
    at gmain.c line 2988
  • #37 IA__gtk_main
    at gtkmain.c line 1237
  • #38 main
    at main.c line 671

Comment 15 Milan Crha 2010-10-05 06:50:53 UTC
Thanks for the update. Thread 18 is in redo_queries, which does gtk+/X calls in a non-mainthread, which is causing this issue. it doesn't crash always, but it should be done.
Comment 16 Milan Crha 2010-10-13 07:40:55 UTC
Created attachment 172238 [details] [review]
evo patch

for evolution;

Invokes items removal always from the main thread, for a price of little waiting on it to be finished and then continues with redo_queries task.
Comment 17 Milan Crha 2010-10-13 07:46:54 UTC
Created commit c83faa7 in evo master (2.91.1+)
Created commit 011e106 in evo gnome-2-32 (2.32.1+)
Comment 18 Milan Crha 2010-10-21 10:29:20 UTC
*** Bug 626641 has been marked as a duplicate of this bug. ***