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 342242 - Crashed on attaching file with drag-n-drop to mail from smb:// location
Crashed on attaching file with drag-n-drop to mail from smb:// location
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.6.x (obsolete)
Other Linux
: High critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 320900 346904 347955 353335 413754 494676 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-05-18 12:17 UTC by Sebastien Bacher
Modified: 2013-09-10 13:56 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Proposed patch (1.54 KB, patch)
2006-05-25 06:14 UTC, Srinivasa Ragavan
committed Details | Review

Description Sebastien Bacher 2006-05-18 12:17:27 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/evolution/+bug/45279

"Subject: Crashed on attaching a .pdf file with drag drop to mail

Distribution: Ubuntu 6.06 (dapper)
Package: Evolution
Priority: Major
Version: GNOME2.14.1 unspecified
Gnome-Distributor: Ubuntu
Synopsis: Crashed on attaching a .pdf file with drag drop to mail
Bugzilla-Product: Evolution
Bugzilla-Component: Mailer
Bugzilla-Version: unspecified
BugBuddy-GnomeVersion: 2.0 (2.14.1)
Description:
Description of the crash:
Crashed on attaching a .pdf file.

Steps to reproduce the crash:
1. clicked "new email" - typed in the receiver's mail-adress
2. open a nautilus window from a smb:// location, containing a .pdf file
3. drag drop it to the mail window -> crash-dialog

Expected Results:
no crash of course

How often does this happen?
first time, can try again and do some tests

Additional Information:
The file was drag dropped form a spatial nautilus window to the mail
window.
The file source of the file was a smb:// location with authentication.
The file's name is: "Debugging with GDB - the GNU Source-Level
Debugger.pdf" Thats no joke ;-)
Perhaps the spaces in the filename are the problem, i can see the grey
crashed evolution window. I can see that the file looks like it has been
attached, but the filename looks like this:
Debugging%
20with%
20GDB%20-%
20the%
...rest is hidden.

I updated ubuntu dapper today and checked afterwards again,
It crashed again with the file drag-dropped from the smb:// location.
It did not crash when i copied the file to my home-dir and drag dropped it from there to the new mail window.

Debugging Information:

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

Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1231750944 (LWP 4921)]
[New Thread -1353532496 (LWP 8152)]
[New Thread -1328116816 (LWP 5303)]
[New Thread -1318454352 (LWP 5302)]
[New Thread -1308591184 (LWP 4952)]
[New Thread -1277809744 (LWP 4934)]
[New Thread -1286464592 (LWP 4933)]
[New Thread -1268917328 (LWP 4931)]
[New Thread -1260262480 (LWP 4929)]
[New Thread -1251869776 (LWP 4928)]
0xffffe410 in __kernel_vsyscall ()
  • #0 __kernel_vsyscall
  • #1 __waitpid_nocancel
    from /lib/tls/i686/cmov/libc.so.6
  • #2 libgnomeui_module_info_get
    from /usr/lib/libgnomeui-2.so.0
  • #3 segv_redirect
    at main.c line 424
  • #4 <signal handler called>
  • #5 camel_mime_part_get_content_type
    at camel-mime-part.c line 682
  • #6 update
    at e-attachment-bar.c line 270
  • #7 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #8 IA__g_closure_invoke
    at gclosure.c line 490
  • #9 signal_emit_unlocked_R
    at gsignal.c line 2438
  • #10 IA__g_signal_emit_valist
    at gsignal.c line 2197
  • #11 IA__g_signal_emit
    at gsignal.c line 2241
  • #12 async_progress_update_cb
    at e-attachment.c line 344
  • #13 gnome_vfs_async_get_job_limit
    from /usr/lib/libgnomevfs-2.so.0
  • #14 g_idle_dispatch
    at gmain.c line 3796
  • #15 IA__g_main_context_dispatch
    at gmain.c line 1916
  • #16 g_main_context_iterate
    at gmain.c line 2547
  • #17 IA__g_main_loop_run
    at gmain.c line 2751

Comment 1 André Klapper 2006-05-18 19:04:52 UTC
sounds pertty much like bug 320900, not the same stacktrace though
Comment 2 Srinivasa Ragavan 2006-05-25 06:05:08 UTC
Nice. This could happen if you got some files with spaces etc. It attaches the file with %20 or so and wont find the file the cache and so crashes. I have fixed this in HEAD along with my patch to support remote shares. Ill attach a patch for stable branch here.
Comment 3 Srinivasa Ragavan 2006-05-25 06:14:35 UTC
Created attachment 66167 [details] [review]
Proposed patch
Comment 4 Srinivasa Ragavan 2006-05-25 06:15:07 UTC
This should fix the issue. This is in HEAD already and should go for stable branch as well.
Comment 5 parthasarathi susarla 2006-07-14 05:39:14 UTC
This patch has been committed to HEAD. And it works. Closing the bug. 
Comment 6 Karsten Bräckelmann 2006-07-17 23:54:21 UTC
mfcabrera (added to the Cc list) reported this crash on IRC, when attaching files from a Samba share to a mail using Evolution 2.6.1.

I can verify the crash and got pretty much the same stacktrace as comment 0. Notably the Null pointer for camel_mime_part_get_content_type() is the same. Evolution 2.6.2. Pasting the top-most, crashing thread below.

Will test the patch later.


REOPENing. According to the comments, this crash is *NOT* fixed in the stable gnome-2-14 branch.

Partha, please read the comments before closing a bug. Note that comment 4 explicitely mentions, that this patch should be committed to the stable branch as well.


0xffffe410 in ?? ()
  • #0 ??
  • #1 ??
  • #2 ??
  • #3 ??
  • #4 __waitpid_nocancel
    from /lib/tls/libpthread.so.0
  • #5 libgnomeui_segv_handle
    at gnome-ui-init.c line 820
  • #6 <signal handler called>
  • #7 camel_mime_part_get_content_type
    at camel-mime-part.c line 683
  • #8 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #9 IA__g_closure_invoke
    at gclosure.c line 490
  • #10 signal_emit_unlocked_R
    at gsignal.c line 2438
  • #11 IA__g_signal_emit_valist
    at gsignal.c line 2197
  • #12 IA__g_signal_emit
    at gsignal.c line 2241
  • #13 async_progress_update_cb
    at e-attachment.c line 344
  • #14 dispatch_sync_job_callback
    at gnome-vfs-job.c line 282
  • #15 g_idle_dispatch
    at gmain.c line 3796
  • #16 IA__g_main_context_dispatch
    at gmain.c line 1916
  • #17 g_main_context_iterate
    at gmain.c line 2547
  • #18 IA__g_main_loop_run
    at gmain.c line 2751
  • #19 bonobo_main
    at bonobo-main.c line 311
  • #20 main
    at main.c line 611

Comment 7 Karsten Bräckelmann 2006-07-17 23:55:51 UTC
Of course, confirming.
Comment 8 Karsten Bräckelmann 2006-07-18 00:02:22 UTC
Oops... NULL pointer for async_progress_update_cb() is the same, too. ;)
Comment 9 Karsten Bräckelmann 2006-07-18 00:03:00 UTC
*** Bug 346904 has been marked as a duplicate of this bug. ***
Comment 10 Srinivasa Ragavan 2006-07-18 04:42:13 UTC
Guenther, Is there anything interesting with the file name. This will happen only when the file is not saved locally by gnome-vfs. It is related to bug 315343. A gnome vfs bug. When the code reaches here, it means the transfer is complete. But it fails to find the file becoz of some error. IIRC when I added GNOME-VFS support to file chooser, I took care of it broadly in the HEAD. I dont think that patch can be back ported to stable, since it can break all sort of freeze. 

1. Can you paste the file name guenther?
   so then, I can confirm the type of the problem.

2. Is it possible for you to try with HEAD?
   If the problem prevails in HEAD, then my assumptions could be wrong.

thanks.


 
Comment 11 Srinivasa Ragavan 2006-07-18 04:45:36 UTC
*Sigh*

I didnt commit this patch to stable. May be this could work around if the file name can non-alphanumeric chars.

Guenther, can you try the patch attached to this bug on the problem?
Comment 12 Karsten Bräckelmann 2006-07-18 17:18:29 UTC
Attaching "text.txt" works, displayed with the appropriate icon.

Attaching "text two.txt" (note the space) crashes Evo. Instead of the MIME Type icon a placeholder like thingy with a big questionmark is displayed, the file name  reads "text%20two.txt", progress is shown as "(0%)".

Specifically tested for a space in the file name, cause I recalled my testing file last time had a space in the name, too. No other special chars. Both files I just tested are empty and created only for testing purpose.


Will try the patch soon, hopefully tonight.
Comment 13 Damien Durand 2006-07-18 20:31:18 UTC
*** Bug 347955 has been marked as a duplicate of this bug. ***
Comment 14 Karsten Bräckelmann 2006-07-22 20:35:28 UTC
The patch fixes the issue for Evo 2.6.2.
Comment 15 Karsten Bräckelmann 2006-07-22 20:37:32 UTC
$ patch -p 0 < ../66167.diff
patching file widgets/misc/e-attachment.c
Hunk #1 succeeded at 400 (offset 5 lines).
Hunk #2 succeeded at 424 (offset 5 lines).
Hunk #3 succeeded at 448 (offset 5 lines).
Hunk #4 succeeded at 457 (offset 5 lines).


Committed the patch to gnome-2-14 branch, too.


2006-07-22  Karsten Bräckelmann  <guenther@rudersport.de>

        * e-attachment.c (e_attachment_new_remote_file): Fix handling of
        remote files containing non-alphanumeric chars. Committed patch by
        Srini. Fixes bug #342242.
Comment 16 Srinivasa Ragavan 2006-07-24 05:56:50 UTC
Thx for the commit Guenther :)
Comment 17 André Klapper 2006-08-29 08:13:03 UTC
*** Bug 353335 has been marked as a duplicate of this bug. ***
Comment 18 André Klapper 2006-08-29 08:15:02 UTC
*** Bug 320900 has been marked as a duplicate of this bug. ***
Comment 19 Susana 2007-03-02 13:23:02 UTC
*** Bug 413754 has been marked as a duplicate of this bug. ***
Comment 20 palfrey 2007-11-08 16:39:39 UTC
*** Bug 494676 has been marked as a duplicate of this bug. ***