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 493053 - crash in Tasks: This crash is 100% repro...
crash in Tasks: This crash is 100% repro...
Status: RESOLVED DUPLICATE of bug 445264
Product: evolution
Classification: Applications
Component: Tasks
2.10.x (obsolete)
Other All
: High critical
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2007-11-03 13:56 UTC by Jonathan S. Shapiro
Modified: 2007-12-06 00:56 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18



Description Jonathan S. Shapiro 2007-11-03 13:56:57 UTC
Version: 2.10

What were you doing when the application crashed?
This crash is 100% reproducible. Open any unread email (the "unread" part probably doesn't matter). For ease of reproduction, choose one that has a large amount of body content. Let the window appear and type CTRL-W before the text can render or the window can be fully drawn. Instant crash.


Distribution: Fedora release 7 (Moonshine)
Gnome Release: 2.18.3 2007-07-02 (Red Hat, Inc)
BugBuddy Version: 2.18.0

System: Linux 2.6.23.1-10.fc7 #1 SMP Fri Oct 19 15:39:08 EDT 2007 i686
X Vendor: The X.Org Foundation
X Vendor Release: 10300000
Selinux: Enforcing
Accessibility: Disabled
GTK+ Theme: Clearlooks
Icon Theme: Fedora

Memory status: size: 141684736 vsize: 141684736 resident: 58793984 share: 33554432 rss: 58793984 rss_rlim: 4294967295
CPU usage: start_time: 1194096639 rtime: 3295 utime: 3094 stime: 201 cutime:25 cstime: 14 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/evolution'

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208224032 (LWP 32504)]
[New Thread -1307575408 (LWP 2531)]
[New Thread -1230939248 (LWP 32626)]
[New Thread -1274426480 (LWP 32531)]
[New Thread -1242563696 (LWP 32518)]
(no debugging symbols found)
0x00110402 in __kernel_vsyscall ()

Thread 1 (Thread -1208224032 (LWP 32504))

  • #0 __kernel_vsyscall
  • #1 waitpid
    from /lib/libpthread.so.0
  • #2 ??
    from /usr/lib/libgnomeui-2.so.0
  • #3 ??
  • #4 <signal handler called>
  • #5 ??
    from /usr/lib/evolution/2.10/libetable.so.0
  • #6 ??
    from /usr/lib/evolution/2.10/libetable.so.0
  • #7 resort_model
    from /usr/lib/evolution/2.10/libetable.so.0
  • #8 ??
    from /lib/libglib-2.0.so.0
  • #9 g_main_context_dispatch
    from /lib/libglib-2.0.so.0
  • #10 ??
    from /lib/libglib-2.0.so.0
  • #11 g_main_loop_run
    from /lib/libglib-2.0.so.0
  • #12 bonobo_main
    from /usr/lib/libbonobo-2.so.0
  • #13 main
  • #0 __kernel_vsyscall


----------- .xsession-errors (70878 sec old) ---------------------
(evolution:24642): Gtk-CRITICAL **: gtk_label_set_text: assertion `GTK_IS_LABEL (label)' failed
(evolution:24642): Gtk-CRITICAL **: gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed
(evolution:24642): e-data-server-WARNING **: Error in execution: Failed to retrieve message
CalDAV Eplugin starting up ...
** (evolution:24941): DEBUG: mailto URL command: evolution --component=mail %s
** (evolution:24941): DEBUG: mailto URL program: evolution
libnm_glib_nm_state_cb: dbus returned an error.
  (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files
(gnome-terminal:24977): Vte-WARNING **: No handler for control sequence `device-control-string' defined.
BBDB spinning up...
(evolution:24941): e-data-server-DEBUG: Loading categories from "/home/shap/.evolution/categories.xml"
(evolution:24941): e-data-server-DEBUG: Loaded 22 categories
--------------------------------------------------
Comment 1 Jonathan S. Shapiro 2007-11-03 14:03:02 UTC
While the automated system identified this as a bug in the Tasks subsystem, I suspect that the bug is in the email component. Perhaps some part of the Tasks subsystem is involved, but from the user perspective I don't use the Tasks subsystem or the calendar subsystem at all.

What seems more likely is that a Gnome widget create or destroy is racing with a window destroy and losing, and either a bad pointer deference is occurring as a result or a callback is getting mishandled or is mis-firing somewhere. The traceback smells to me like a localized logic/race error in the window handling rather than any problem that is specific to the implementation of evolution's application-level function.
Comment 2 Rob Bradford 2007-11-03 15:19:27 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. Can you get us a stack trace with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so and reopen this bug or report a new one. Thanks in advance!
Comment 3 Jonathan S. Shapiro 2007-11-03 15:27:41 UTC
Because we do secure software, I'm very reluctant to install *ANY* package I don't absolutely need on a production machine. I'll basically need to reload the machine from scratch afterwards.

Could I trouble you to attempt to reproduce it at the keyboard first and see if you can get a clean trace? Procedure:

  1. Disable your preview pane
  2. Select, but do not open, any message you like that hasn't yet been read.
  3. Hit enter to pop up the message view window
  4. As soon as the *outline* of the per-message window appears, type
     control-W to close that window.

I think there is a good chance that you can reproduce this in just a few seconds. I've seen it occur consistently on a wide range of machines. It helps if you are a touch typist. or you pre-position your fingers.

In my case, the occurrence scenario is that I've hit "enter" on the wrong message, and I'm trying to clear the window so I can move on -- I'm literally not waiting for any text to appear. Once the text appears, closing the window does not cause a crash, so my "workaround" is simply to be a little more patient.
Comment 4 Tobias Mueller 2007-12-06 00:56:57 UTC
Thanks for taking the time to report this bug.
This particular bug has already been reported into our bug tracking system, but the maintainers need more information to fix the bug. Could you please answer the questions in the other report in order to help the developers?


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