GNOME Bugzilla – Bug 628723
crash in efhd_format_attachment at em-format-html-display.c line 427
Last modified: 2013-07-24 12:17:07 UTC
What were you doing when the application crashed? Opening an email with an attachment. Distribution: Debian squeeze/sid Gnome Release: 2.30.2 2010-07-17 (Debian) BugBuddy Version: 2.30.0 System: Linux 2.6.35-trunk-amd64 #1 SMP Tue Aug 17 08:22:25 UTC 2010 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 10707000 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: gnome GTK+ Modules: gnomebreakpad, canberra-gtk-module Memory status: size: 759812096 vsize: 759812096 resident: 47226880 share: 23519232 rss: 47226880 rss_rlim: 18446744073709551615 CPU usage: start_time: 1283536326 rtime: 130 utime: 122 stime: 8 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/evolution' [Thread debugging using libthread_db enabled] [New Thread 0x7fec4999b710 (LWP 2667)] [New Thread 0x7fec363c4710 (LWP 2661)] [New Thread 0x7fec36bc5710 (LWP 2660)] [New Thread 0x7fec4a19c710 (LWP 2654)] [New Thread 0x7fec4a99d710 (LWP 2653)] [New Thread 0x7fec4b19e710 (LWP 2652)] [New Thread 0x7fec4bbc8710 (LWP 2651)] [New Thread 0x7fec4c3c9710 (LWP 2650)] 0x00007fec5a083b4d in waitpid () from /lib/libpthread.so.0
+ Trace 223540
Thread 2 (Thread 0x7fec4999b710 (LWP 2667))
Inferior 1 [process 2649] will be detached. Quit anyway? (y or n) [answered Y; input not from terminal] ---- Critical and fatal warnings logged during execution ---- ** evolution **: em_format_add_puri: assertion `emf->pending_uri_level != NULL' failed ----------- .xsession-errors --------------------- ** (gnome-screensaver:2497): WARNING **: Config key not handled: /desktop/gnome/lockdown/disable_application_handlers ** (gnome-screensaver:2497): WARNING **: Config key not handled: /desktop/gnome/lockdown/disable_command_line ** (gnome-screensaver:2497): WARNING **: Config key not handled: /desktop/gnome/lockdown/disable_printing ** (gnome-screensaver:2497): WARNING **: Config key not handled: /desktop/gnome/lockdown/disable_print_setup ** (gnome-screensaver:2497): WARNING **: Config key not handled: /desktop/gnome/lockdown/disable_save_to_disk ** (evolution:2627): CRITICAL **: em_format_add_puri: assertion `emf->pending_uri_level != NULL' failed (evolution:2646): Unique-DBus-WARNING **: Error while sending message: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy bl ** (evolution:2649): CRITICAL **: em_format_add_puri: assertion `emf->pending_uri_level != NULL' failed --------------------------------------------------
may be fixed under bug 612082
*** Bug 629109 has been marked as a duplicate of this bug. ***
*** Bug 630905 has been marked as a duplicate of this bug. ***
Similar downstream bug from 3.0.2: https://bugzilla.redhat.com/show_bug.cgi?id=716616
I experienced a crash on Evolution 3.4.4 with Debian Wheezy with almost exactly the same backtrace. After some debugging I found the problem to be in the tree data structure for managing pending URI processing (PURI). While em_format_pull_level() from em-format.c always goes one level up in the tree structure, em_format_push_level() doesn't increase the height of the tree as expected. After the second push operation, the function starts to add the node to the same level instead of creating a new one. When trying to pull these from the "stack" again, pending_uri_level permaturely becomes a NULL pointer, causing crashes in other parts of the program. I don't have enough knowledge to be able to tell how data structure is supposed to work exactly, especially if it should be possible to have multiple entries on the root level, i.e. if the following sequence of operation is valid: push pull push pull When debugging the crash, I just noticed that the problematic object contained a proper root node, but just because it was always created using a clone operation. Clone calls em_format_clear_puri_tree() on the new object, which produces a common root node using an unbalanced call to em_format_push_level(). However, a fresh object always has a NULL pointer instead, which might lead to similar problems, depending how the tree structure is used. Maybe em_format_clear_puri_tree() should also be called from emf_init()? I created a patch that fixes the problem at hand (see attachment), but someone with more knowledge in this area should still check if the object lifecycle for the tree root actually works as intended.
Created attachment 250013 [details] [review] Possible fix for puri tree structure Patch against Evolution 3.4.4
Closing as OBSOLETE since the affected code was completely rewritten when we moved to WebKit in 3.6.