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 607781 - crash trying to cancel a mailbox update task
crash trying to cancel a mailbox update task
Status: RESOLVED DUPLICATE of bug 558079
Product: evolution
Classification: Applications
Component: Mailer
2.28.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2010-01-22 16:20 UTC by Brian J. Murrell
Modified: 2010-01-28 07:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Brian J. Murrell 2010-01-22 16:20:39 UTC
I was trying to cancel a mailbox update task by clicking on the task's cancel button on the status bar and eventually got this crash:

Thread 1 (Thread 31429)

  • #0 camel_msgport_push
    at camel-msgport.c line 334
  • #1 camel_operation_cancel
    at camel-operation.c line 305
  • #2 cancel_wrapper
    at e-activity-handler.c line 394
  • #3 button_press_event_cb
    at e-task-widget.c line 95
  • #4 IA__g_cclosure_marshal_VOID__VOID
    at /build/buildd/glib2.0-2.22.3/gobject/gmarshal.c line 77
  • #5 IA__g_closure_invoke
    at /build/buildd/glib2.0-2.22.3/gobject/gclosure.c line 767
  • #6 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 3247
  • #7 IA__g_signal_emit_valist
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 2980
  • #8 IA__g_signal_emit_by_name
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 3074
  • #9 button_clicked
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtktoolbutton.c line 707
  • #10 IA__g_cclosure_marshal_VOID__VOID
    at /build/buildd/glib2.0-2.22.3/gobject/gmarshal.c line 77
  • #11 IA__g_closure_invoke
    at /build/buildd/glib2.0-2.22.3/gobject/gclosure.c line 767
  • #12 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 3247
  • #13 IA__g_signal_emit_valist
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 2980
  • #14 IA__g_signal_emit
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 3037
  • #15 IA__gtk_button_clicked
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtkbutton.c line 1111
  • #16 gtk_real_button_released
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtkbutton.c line 1707
  • #17 IA__g_cclosure_marshal_VOID__VOID
    at /build/buildd/glib2.0-2.22.3/gobject/gmarshal.c line 77
  • #18 g_type_class_meta_marshal
    at /build/buildd/glib2.0-2.22.3/gobject/gclosure.c line 878
  • #19 IA__g_closure_invoke
    at /build/buildd/glib2.0-2.22.3/gobject/gclosure.c line 767
  • #20 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 3177
  • #21 IA__g_signal_emit_valist
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 2980
  • #22 IA__g_signal_emit
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 3037
  • #23 IA__gtk_button_released
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtkbutton.c line 1103
  • #24 gtk_button_button_release
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtkbutton.c line 1599
  • #25 _gtk_marshal_BOOLEAN__BOXED
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtkmarshalers.c line 84
  • #26 g_type_class_meta_marshal
    at /build/buildd/glib2.0-2.22.3/gobject/gclosure.c line 878
  • #27 IA__g_closure_invoke
    at /build/buildd/glib2.0-2.22.3/gobject/gclosure.c line 767
  • #28 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 3285
  • #29 IA__g_signal_emit_valist
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 2990
  • #30 IA__g_signal_emit
    at /build/buildd/glib2.0-2.22.3/gobject/gsignal.c line 3037
  • #31 gtk_widget_event_internal
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtkwidget.c line 4767
  • #32 IA__gtk_propagate_event
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtkmain.c line 2417
  • #33 IA__gtk_main_do_event
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtkmain.c line 1622
  • #34 gdk_event_dispatch
    at /build/buildd/gtk+2.0-2.18.3/gdk/x11/gdkevents-x11.c line 2369
  • #35 g_main_dispatch
    at /build/buildd/glib2.0-2.22.3/glib/gmain.c line 1960
  • #36 IA__g_main_context_dispatch
    at /build/buildd/glib2.0-2.22.3/glib/gmain.c line 2513
  • #37 g_main_context_iterate
    at /build/buildd/glib2.0-2.22.3/glib/gmain.c line 2591
  • #38 IA__g_main_loop_run
    at /build/buildd/glib2.0-2.22.3/glib/gmain.c line 2799
  • #39 bonobo_main
    at bonobo-main.c line 311
  • #40 main
    at main.c line 732

Comment 1 Brian J. Murrell 2010-01-22 16:23:57 UTC
During filing, bug 558079 was flagged as a candidate that this is a possible dup of.  Unfortunately when being asked if they could be dups, one has lost all view of the bug being filed, including stack traces, etc. so it's difficult to try to "remember" what the one being filed looks like.

I will leave it up to the experts to decide the duplicity.  Please do feel free to close any of my bugs that you feel are duplicate.  I would rather have the closed and pointed to the real bug than having duplicate copies of forty-eleven bugs open and not being assessed because they are duplicates of bugs that are being worked.
Comment 2 Fabio Durán Verdugo 2010-01-23 00:28:29 UTC
I think the trace is the same, what do you think? Akhil?, Milan?
Comment 3 Milan Crha 2010-01-28 07:02:13 UTC
It can be the same bug. There is an invalid msgport pointer in the bug 558079,
but here are three different places where the crash could happen, namely:

> Thread 22 (Thread 839):
> #0  0x002a991b in camel_pstring_free (s=0x93713650 ".Ir9xcH_21978,
>    <435C366F075ED211B12200204840172D05869453@petitsuix.coe.int>")
>    at camel-string-utils.c:266
>
> Thread 3 (Thread 31488):
> #0  sYSMALLOc (av=..., bytes=...) at malloc.c:3410
>
> Thread 1 (Thread 31429):
> #0  0x0029b771 in camel_msgport_push (msgport=0x3ff00000, msg=0xb116bc0)
>    at camel-msgport.c:334

These three threads are doing something, where the rest are waiting only. This is the reason why I liked the old good gdb traces with <signal handler called> notes in them. One was able to see where exactly the signal was called (it used to be in more than one thread sometimes, in the crashing one, and in the main thread).

Anyway, let's mark this as a duplicate, it would be quite good coincidence to have crashing in other threads and have the same Thread 1.

*** This bug has been marked as a duplicate of bug 558079 ***