GNOME Bugzilla – Bug 352109
evolution crashes when attempting to open an attachment on Solaris x86
Last modified: 2013-09-14 16:49:35 UTC
Steps to reproduce: 1. Launch evolution and setup an IMAP mail account. 2. Browse to a mail contining an attachmet, pdf, gif or txt, for example. 3. Right click on attachment and select to open it in Image viewer, Evince or other application. On Solaris x86:evolution crashes On Solaris sparc:the following an error is displayed "could not write data wrong file number" Stack trace: ----------------- lwp# 1 / thread# 1 -------------------- fe365487 __pollsys (84168f8, 7, 8046f38, 0) + 7 fe31c4d7 poll (84168f8, 7, 8f658) + 52 fe3f197d g_main_context_iterate (809c978, 1, 1, 80813d0) + 399 fe3f1c10 g_main_context_iteration (809c978, 1) + 88 fe7206c2 gtk_main_iteration (89709a8, 88db5e0, fa5f792c, 8047018, fa5a7661, 0) + 2a fa5b197f mail_msg_wait (4c) + 19b fa5a7661 em_utils_temp_save_part (88ab470, 8812d88) + d1 fa5a3487 emp_apps_open_in (897e460, 8719240, 0) + 3b feefd023 ep_activate (897e318, 881e1f8) + 53 fe93eb99 g_cclosure_marshal_VOID__VOID (895f340, 0, 1, 804721c, 804717c, 0) + 55 fe92a46a g_closure_invoke (895f340, 0, 1, 804721c, 804717c) + 112 fe93e418 signal_emit_unlocked_R (81966a0, 0, 897e318, 0, 804721c) + 754 fe93d71d g_signal_emit_valist (897e318, a5, 0, 8047488) + 8cd fe93d8b9 g_signal_emit (897e318, a5, 0) + 29 fe8280b8 gtk_widget_activate (897e318) + 40 fe732412 gtk_menu_shell_activate_item (8340a40, 897e318, 1) + e2 fe731889 gtk_menu_shell_button_release (8340a40, 8973b28) + f5 fe729ebf gtk_menu_button_release (8340a40, 8973b28, 80f4cc8) + 6b fe722f99 _gtk_marshal_BOOLEAN__BOXED (8161d08, 8047630, 2, 80476ec, 804764c, fe729e54) + 71 fe92a765 g_type_class_meta_marshal (8161d08, 8047630, 2, 80476ec, 804764c, b4) + 4d fe92a46a g_closure_invoke (8161d08, 8047630, 2, 80476ec, 804764c) + 112 fe93e5dd signal_emit_unlocked_R (809ed78, 0, 8340a40, 804786c, 80476ec) + 919 fe93d4b3 g_signal_emit_valist (8340a40, 2e, 0, 8047960) + 663 fe93d8b9 g_signal_emit (8340a40, 2e, 0, 8973b28, 8047984) + 29 fe827f2a gtk_widget_event_internal (8340a40, 8973b28) + 212 fe827bb9 gtk_widget_event (8340a40, 8973b28) + 99 fe721b0e gtk_propagate_event (8340a40, 8973b28) + 96 fe720b80 gtk_main_do_event (8973b28, 0) + 3b0 fe9ef792 gdk_event_dispatch (809c930, 0, 0) + 56 fe3f0497 g_main_dispatch (809c978) + 1db fe3f1595 g_main_context_dispatch (809c978) + 85 fe3f19b5 g_main_context_iterate (809c978, 1, 1, 80813d0) + 3d1 fe3f1fba g_main_loop_run (8161810) + 1ba febdf22e bonobo_main (8047c94, 8047be0, feffa7c0, 0, fe3afa80, 400) + 5e 08063cbc main (1, 8047c24, 8047c2c) + 3f8 08058fde _start (1, 8047cfc, 0, 8047d13, 8047d2c, 8047d40) + 7a ----------------- lwp# 2 / thread# 2 -------------------- 00010101 ???????? () ----------------- lwp# 3 / thread# 3 -------------------- fe365487 __pollsys (fa28dce0, 1, 0, 0) + 7 fe321182 pselect (2c, fa28dee0, fe3ad990, fe3ad990, 0, 0) + 19e fe321474 select (2c, fa28dee0, 0, 0, 0) + 7e feddf1e7 e_msgport_wait (8197b78, 0, fa3d0000, fe3ac000, fe363e1b, 0) + b3 feddf9a7 thread_dispatch (8197b18) + 7f fe36480b _thr_setup (fa3d0000) + 51 fe364a60 _lwp_start (fa3d0000, 0, 0, 0, 0, 0) ----------------- lwp# 4 / thread# 4 -------------------- fe365487 __pollsys (fa18dbd0, 1, 0, 0) + 7 fe321182 pselect (4e, fa18dee0, fe3ad990, fe3ad990, 0, 0) + 19e fe321474 select (4e, fa18dee0, 0, 0, 0) + 7e feddf1e7 e_msgport_wait (8234f90, 0, fa3d0400, fe3ac000, fe363e1b, 0) + b3 feddf9a7 thread_dispatch (8234e80) + 7f fe36480b _thr_setup (fa3d0400) + 51 fe364a60 _lwp_start (fa3d0400, 0, 0, 0, 0, 0) ----------------- lwp# 6 / thread# 6 -------------------- fe365487 __pollsys (fa08dd20, 1, 0, 0) + 7 fe321182 pselect (24, fa08dee0, fe3ad990, fe3ad990, 0, 0) + 19e fe321474 select (24, fa08dee0, 0, 0, 0) + 7e feddf1e7 e_msgport_wait (8197a58, 0, fa3d0800, fe3ac000, fe363e1b, 0) + b3 feddf9a7 thread_dispatch (81979f8) + 7f fe36480b _thr_setup (fa3d0800) + 51 fe364a60 _lwp_start (fa3d0800, 0, 0, 0, 0, 0) ----------------- lwp# 7 / thread# 7 -------------------- fe365487 __pollsys (80f38c0, a, 0, 0) + 7 fe31c4d7 poll (80f38c0, a, ffffffff) + 52 fe3f197d g_main_context_iterate (8310f00, 1, 1, 825a450) + 399 fe3f1fba g_main_loop_run (8425530) + 1ba fea975ea link_io_thread_fn (0) + 1e fe40b783 g_thread_create_proxy (825a450) + 11b fe36480b _thr_setup (fa3d0c00) + 51 fe364a60 _lwp_start (fa3d0c00, 0, 0, 0, 0, 0) ----------------- lwp# 8 / thread# 8 -------------------- fe365487 __pollsys (f9ecfd00, 1, 0, 0) + 7 fe321182 pselect (28, f9ecfee0, fe3ad990, fe3ad990, 0, 0) + 19e fe321474 select (28, f9ecfee0, 0, 0, 0) + 7e feddf1e7 e_msgport_wait (8197ae8, 0, fa3d1000, fe3ac000, fe363e1b, 0) + b3 feddf9a7 thread_dispatch (8197a88) + 7f fe36480b _thr_setup (fa3d1000) + 51 fe364a60 _lwp_start (fa3d1000, 0, 0, 0, 0, 0) Other information:
The cause of the problem is because gnome_vfs_write requires a GnomeVFSFileSize as its last parameter but a ssize_t is given. sizeof (ssize_t) is 4 and sizeof (GnomeVFSFileSize) is 8 so the local variable seekalbe is overwritten by the call of gnome_vfs_write. As I checked, sizeof (ssize_t) is 4 and sizeof (GnomeVFSFileSize) is 8 too on Linux, so there should be the same problem on Linux, but I can not reproduce the bug on my fedro5, maybe it's because the layout of the statk is a little different from Solaris.
New trace: t@4 (l@4) signal SEGV (no mapping at the fault address) in stream_write at line 210 in file "camel-stream-vfs.c" 210 seekable->position += nwritten; (dbx) bt current thread: t@4 =>[1] stream_write(stream = 0x8bf2848, buffer = 0x8c8d048 "Actually, we don't have many options, so let's evaluate each one of\n them:\n\n o Rewrite apps:\n - Lot of work: more resources\n - Alternative GNOME community: competition\n - We'd be behind Novell for some time\n - We'd need for Java to be freed\n + Avoids the Mono dependency\n\n o Desktop switch:\n - C++ ABI issue\n - It'd be a change\n + Avoids the Mono dependency\n + More apps\n\n o Go with Mono:\n - New stack and new teams\n - Against Java\n " ..., n = 3677U), line 210 in "camel-stream-vfs.c" [2] camel_stream_write(stream = 0x8bf2848, buffer = 0x8c8d048 "Actually, we don't have many options, so let's evaluate each one of\n them:\n\n o Rewrite apps:\n - Lot of work: more resources\n - Alternative GNOME community: competition\n - We'd be behind Novell for some time\n - We'd need for Java to be freed\n + Avoids the Mono dependency\n\n o Desktop switch:\n - C++ ABI issue\n - It'd be a change\n + Avoids the Mono dependency\n + More apps\n\n o Go with Mono:\n - New stack and new teams\n - Against Java\n " ..., n = 3677U), line 119 in "camel-stream.c" [3] do_write(stream = 0x8b93808, buf = 0xcb40dccd "Þ@ËhÞ@Ë\x88²^?ÑLÝ@ËpÑ|ÑxÝ@ËÈÝ@ËÌÝ@ËD^B\x8dÊ^X", n = 3677U), line 324 in "camel-stream-filter.c" [4] camel_stream_write(stream = 0x8b93808, buffer = 0xcb40ce70 "Actually, we don't have many options, so let's evaluate each one of\n them:\n\n o Rewrite apps:\n - Lot of work: more resources\n - Alternative GNOME community: competition\n - We'd be behind Novell for some time\n - We'd need for Java to be freed\n + Avoids the Mono dependency\n\n o Desktop switch:\n - C++ ABI issue\n - It'd be a change\n + Avoids the Mono dependency\n + More apps\n\n o Go with Mono:\n - New stack and new teams\n - Against Java\n " ..., n = 3677U), line 119 in "camel-stream.c" [5] camel_stream_write_to_stream(stream = 0x8b36634, output_stream = 0x8b93808), line 273 in "camel-stream.c" [6] write_to_stream(data_wrapper = 0x8b93448, stream = 0x8b93808), line 147 in "camel-data-wrapper.c" [7] write_to_stream(data_wrapper = 0x8b93448, stream = 0x8b93808), line 163 in "camel-imap-wrapper.c" [8] camel_data_wrapper_write_to_stream(data_wrapper = 0x8b93448, stream = 0x8b93808), line 175 in "camel-data-wrapper.c" [9] decode_to_stream(data_wrapper = 0x8b93448, stream = 0x8bf2848), line 215 in "camel-data-wrapper.c" [10] camel_data_wrapper_decode_to_stream(data_wrapper = 0x8b93448, stream = 0x8bf2848), line 240 in "camel-data-wrapper.c" [11] save_part_save(mm = 0x8b3bba0), line 2112 in "mail-ops.c" [12] mail_msg_received(e = 0x81dda60, msg = 0x8b3bba0, data = (nil)), line 570 in "mail-mt.c" [13] thread_received_msg(e = 0x81dda60, m = 0x8b3bba0), line 987 in "e-msgport.c" [14] thread_dispatch(din = 0x81dda60), line 1068 in "e-msgport.c" [15] _thr_setup(0xcb2f0000), at 0xcfd2832f [16] _lwp_start(), at 0xcfd28580
signature of gnome_vfs_write: GnomeVFSResult gnome_vfs_write (GnomeVFSHandle *handle, gconstpointer buffer, GnomeVFSFileSize bytes, GnomeVFSFileSize *bytes_written);
Created attachment 71238 [details] [review] patch to fix the bug
wang, the patch looks OK to commit but few more places this conversion is required. The function headers has to be changed If im not wrong. .
Hmm not really. They may not be really required. Please commit.
The patch has been committed into trunk.