Hopefully already fixed by the thread-safety improvements I made to EAttachment in Evolution 3.9.2.

Another similar downstream bug report around EAttachment:
https://bugzilla.redhat.com/show_bug.cgi?id=978321

Description of problem:
Killed while adding attachments.

Version-Release number of selected component:
evolution-3.8.3-2.fc19

+ Trace 232150

(In reply to comment #1)
> Hopefully already fixed by the thread-safety improvements I made to EAttachment
> in Evolution 3.9.2.

Did it reach gnome-3-8 too? Though I guess it didn't.

For me this is totally reproducible with evolution-3.8.3-2.fc19.x86_64 when adding attachments. Means, I cannot send any attachments, this is pretty bad. 

If possible, please backport this to 3.8, too

Could you install debuginfo packages for evolution-data-server and evolution, and then reproduce this under valgrind, please? It does not crash necessarily, the valgrind can survive certain errors, and logs about them only. The valgrind command looks like this:
   $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt

It'll either prove Matthew's theory, or shed more light on the issue. I still do not understand why I do not see this, while others do. Does this depend on actual attachment type?

*** Bug 706425 has been marked as a duplicate of this bug. ***

*** Bug 706990 has been marked as a duplicate of this bug. ***

Just hit this bug on my machine too

I'm afraid this is not fixed at in Evolution 3.10.1 - I get exactly the same thing. Of course, it could be a gtk+ file-selector bug (plenty of those to go around I guess).

Exactly the same trace I filed vs. Evo 3.8.x in bug#706990. It's unclear to me that running evolution under valgrind is going to work so well ;-)

This was a 15Mb attachment, and (I guess) while it was attaching, I started to (try to) adjust the CC / edit the thing but that may be un-related.

Program received signal SIGSEGV, Segmentation fault.
0xb58bdd22 in g_file_info_get_icon (info=info@entry=0xe68a818) at gfileinfoProgram received signal SIGSEGV, Segmentation fault.
0xb58bdd22 in g_file_info_get_icon (info=info@entry=0xe68a818) at gfileinfo.c:1662
1662	gfileinfo.c: No such file or directory.
(gdb) bt

+ Trace 232728

(gdb) p *info
$1 = {parent_instance = {g_type_instance = {g_class = 0xa1ff538}, ref_count = 2, qdata = 0x0}, attributes = 0xcb5d800, mask = 0x1}
(gdb) p attr
$2 = 1048587
(gdb) p g_file_info_find_value (info, attr)
Program received signal SIGSEGV, Segmentation fault.
0xb58ba306 in g_file_info_find_place (info=info@entry=0x8078668, attribute=attribute@entry=889) at gfileinfo.c:510
... back up ...
(gdb) p *info->attributes
$5 = {data = 0xcbb7190 "\001", len = 12}
(gdb) p (GFileAttribute *)info->attributes->data
$6 = (GFileAttribute *) 0xcbb7190
(gdb) p $6[0]
$7 = {attribute = 1048577, value = {type = G_FILE_ATTRIBUTE_TYPE_UINT32, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {boolean = 1, int32 = 1, 
      uint32 = 1, int64 = 1, uint64 = 1, string = 0x1 <Address 0x1 out of bounds>, obj = 0x1, stringv = 0x1}}}
(gdb) p $6[1]
$8 = {attribute = 1048582, value = {type = G_FILE_ATTRIBUTE_TYPE_BYTE_STRING, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {boolean = 257868200, 
      int32 = 257868200, uint32 = 257868200, int64 = 257868200, uint64 = 257868200, string = 0xf5ec1a8 "Partner-signed.pdf", obj = 0xf5ec1a8, 
      stringv = 0xf5ec1a8}}}
(gdb) p $6[2]
$9 = {attribute = 1048583, value = {type = G_FILE_ATTRIBUTE_TYPE_STRING, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {boolean = 295169440, 
      int32 = 295169440, uint32 = 295169440, int64 = 295169440, uint64 = 295169440, string = 0x1197eda0 "Partner-signed.pdf", obj = 0x1197eda0, 
      stringv = 0x1197eda0}}}
(gdb) p $6[3]
$10 = {attribute = 1048584, value = {type = G_FILE_ATTRIBUTE_TYPE_STRING, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {boolean = 284880224, 
      int32 = 284880224, uint32 = 284880224, int64 = 284880224, uint64 = 284880224, string = 0x10faed60 "Partner-signed.pdf", obj = 0x10faed60, 
      stringv = 0x10faed60}}}
(gdb) p $6[4]
$11 = {attribute = 1048585, value = {type = G_FILE_ATTRIBUTE_TYPE_STRING, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {boolean = 201357280, 
      int32 = 201357280, uint32 = 201357280, int64 = 201357280, uint64 = 201357280, string = 0xc0077e0 "Partner-signed.pdf", obj = 0xc0077e0, 
      stringv = 0xc0077e0}}}
(gdb) p $6[5]
$12 = {attribute = 1048587, value = {type = G_FILE_ATTRIBUTE_TYPE_OBJECT, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {boolean = 284876880, 
      int32 = 284876880, uint32 = 284876880, int64 = 284876880, uint64 = 284876880, string = 0x10fae050 "y\003", obj = 0x10fae050, 
      stringv = 0x10fae050}}}
(gdb) p $6[6]
$13 = {attribute = 1048588, value = {type = G_FILE_ATTRIBUTE_TYPE_STRING, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {boolean = 225976296, 
      int32 = 225976296, uint32 = 225976296, int64 = 225976296, uint64 = 225976296, string = 0xd781fe8 "application/pdf", obj = 0xd781fe8, 
      stringv = 0xd781fe8}}}
(gdb) p $6[7]
$14 = {attribute = 1048589, value = {type = G_FILE_ATTRIBUTE_TYPE_STRING, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {boolean = 225976344, 
      int32 = 225976344, uint32 = 225976344, int64 = 225976344, uint64 = 225976344, string = 0xd782018 "application/pdf", obj = 0xd782018, 
      stringv = 0xd782018}}}
(gdb) p $6[8]
$15 = {attribute = 1048590, value = {type = G_FILE_ATTRIBUTE_TYPE_UINT64, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {boolean = 13814571, 
      int32 = 13814571, uint32 = 13814571, int64 = 13814571, uint64 = 13814571, string = 0xd2cb2b <Address 0xd2cb2b out of bounds>, 
      obj = 0xd2cb2b, stringv = 0xd2cb2b}}}
(gdb) p $6[9]
$16 = {attribute = 1048591, value = {type = G_FILE_ATTRIBUTE_TYPE_UINT64, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {boolean = 13819904, 
      int32 = 13819904, uint32 = 13819904, int64 = 13819904, uint64 = 13819904, string = 0xd2e000 <Address 0xd2e000 out of bounds>, 
      obj = 0xd2e000, stringv = 0xd2e000}}}
(gdb) p $6[10]
$17 = {attribute = 1048595, value = {type = G_FILE_ATTRIBUTE_TYPE_OBJECT, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {boolean = 259894904, 
      int32 = 259894904, uint32 = 259894904, int64 = 259894904, uint64 = 259894904, string = 0xf7dae78 "\210\223f\n\001", obj = 0xf7dae78, 
      stringv = 0xf7dae78}}}
(gdb) p $6[11]
$18 = {attribute = 10485761, value = {type = G_FILE_ATTRIBUTE_TYPE_BYTE_STRING, status = G_FILE_ATTRIBUTE_STATUS_UNSET, u = {
      boolean = 372179368, int32 = 372179368, uint32 = 372179368, int64 = 372179368, uint64 = 372179368, 
      string = 0x162f01a8 "/home/michael/.cache/thumbnails/normal/1c8dfe588c32117a58c4342c6047a27e.png", obj = 0x162f01a8, 
      stringv = 0x162f01a8}}}
(gdb) p $6[12]
$19 = {attribute = 3132799674, value = {type = 186, status = (G_FILE_ATTRIBUTE_STATUS_ERROR_SETTING | unknown: 184), u = {boolean = -1162167622, 
      int32 = -1162167622, uint32 = 3132799674, int64 = -4991471925827290438, uint64 = 13455272147882261178, 
      string = 0xbabababa <Address 0xbabababa out of bounds>, obj = 0xbabababa, stringv = 0xbabababa}}}
(gdb)

unfortunately debugging:

(gdb) p g_file_info_find_place (0xe68a818, attr)

Breakpoint 1, g_file_info_find_place (info=0x101, attribute=889) at gfileinfo.c:503
503	in gfileinfo.c

We start to get some pretty vicious lies - info=0x101 by the time we get in there, which is clearly bogus, and (I assume) a typical lie of gdb ;-)

With some:

p info=0xe68a818

inside the fn. we can convince it to totter a bit further along; that eventually returns 0 via a reasonable binary search (AFAICS), but I suspect the 'attribute' value I used was too low - hey ho. Will try to catch it misbehaving next time it happens.

Maybe this recent Matthew's commit will help here:
https://git.gnome.org/browse/evolution/commit/?id=03972535919d96d55a409988f4436e0a5e54b96b

Lovely - looking forward to 3.10.2 - it looks like it'll be in that :-)

It seems the 3.10.2 is still afffected, at least according to downstream:
https://bugzilla.redhat.com/show_bug.cgi?id=1032284

Description of problem:
I atached atachment to mail message which I wanted to send. Then I send and then Evolution crashed.

Version-Release number of selected component:
evolution-3.10.2-1.fc20

Additional info:
reporter:       libreport-2.1.9
backtrace_rating: 4
cmdline:        evolution
crash_function: g_file_info_get_icon
executable:     /usr/bin/evolution
kernel:         3.11.6-300.fc20.x86_64

Core was generated by `evolution'.
Program terminated with signal SIGSEGV, Segmentation fault.

+ Trace 232806

Bug is still there.

I'm seeing this as well in 3.10.2 (the evolution-3.10.2-2.fc20.x86_64 package from Fedora 20 pre-release, FWIW).

For me, it happened when adding an attachment, not removing it like the title of this bug report suggests.  Unlike comment 13, however, Evolution crashed for me *before* I clicked the "Send" button.

Well, it seems that this never ending bug can be easily workaround by generating file thumbnail listing it in nautilus, and then added as attachment. Or... maybe just switching off thumbnail preview of attachment in Evolution?

I enjoy the crash two to three times a day - it does wonders for my mail editing - it happens most with large files, and a busy file-system (it seems). Also, where those files have been edited recently (ie. may not be thumbnailed already I guess). So try saving a 70Mb PPT file or something, and then trying to attach it.

unfortunately the file->save -> evolution->attach cycle is one that I go around a lot and ...

Anything that would turn this off would be wonderful, is there a setting somewhere: "do old-style, synchronous, non-crashing attach" ;-) ... or "disable thumbnails I don't need" or ... ? ;-)

Ran into this today. Just a one time thing though. Didn't happen when I re-ran evolution and attached the same files again.

The pdf file in question was moved right before I tried to attach it, and I don't think a thumbnail had been generated yet when I tried to attach it and evolution crashed. I hadn't edited the file, just moved it to a new location.

(In reply to comment #18)
> Ran into this today. Just a one time thing though. Didn't happen when I re-ran
> evolution and attached the same files again.
> 
> The pdf file in question was moved right before I tried to attach it, and I
> don't think a thumbnail had been generated yet when I tried to attach it and
> evolution crashed. I hadn't edited the file, just moved it to a new location.

+1

I've been meeting to file a similar comment. I've noticed this issue as well.

If the file just got created, and I tried to attach it too quickly, that's when it crashes. I think that thumbnailing (or something around it) might have something to do with it.

A crash with a similar backtrace happened too with Evolution 3.8.5-2+b1 from Debian Sid/unstable.

Milan and Matthew, what information do you need to further debug this issue and solve it? Were you able to reproduce this with the instructions/circumstances reported by others?

I tried to reproduce this, with a ~35MB png image, even with cleared-up ~/.cache/thumbnails, but no luck, no crash here.

Try with LibreOffice ODS or ODT documents - smaller :) Make sure that nautilus file browser window is closed or at least not listing added files - cause of this thumbnail will be generated before adding attachment.
This bug does not always show, it seems that it is a race condition. Attach files using "Add attachment..." button. I'm sure If You will create 10 documents (PDF, ODS, ODT) and try add them one by one then You should catch this bug.

Right, I can reproduce the crash now, and one related when I remove attachments from the attachment bar. It's not 100% reliable crash, but I'm fine with this too. Let me dig into it.

One misplaced unref, and it causes so much trouble. Both the above crashes are really related, both are about the GIcon from the GFileInfo. When the attachment is loaded, the e_attachment_set_file_info() is called twice with the same file info. It's not that much trouble, but sometimes the attachment_update_icon_column_idle_cb() could get the icon from the file_info, but not the thumbnail path, which resulted in a call of create_system_thumbnail(), which, if it succeeded with the icon creation, first unrefs non-NULL passed-in icon. The thing is that this icon is from the GFileInfo, and the g_file_info_get_icon() doesn't references it, thus the under was done on an internal member of the GFileInfo, which could later crash in both cases, when there was done a repeated e_attachment_set_file_info(), or when an attachment was removed, due to the call g_object_unref() on an already freed object. If it sounds complicated, then do not bother with the finding, just:

Created commit d64150a in evo master (3.11.5+) [1]
Created commit d516363 in evo gnome-3-10 (3.10.4+)

[1] https://git.gnome.org/browse/evolution/commit/?id=d64150a

Good catch!

Milan, thank you for getting this fixed. Hopefully the 3.10.x users can confirm it.

Could you also add it to the 3.8 branch please?

(In reply to comment #26)
> Could you also add it to the 3.8 branch please?

The patch is basically the same, and gnome-3-8 branch is basically death for upstream.

(In reply to comment #27)
> (In reply to comment #26)
> > Could you also add it to the 3.8 branch please?
> 
> The patch is basically the same, and gnome-3-8 branch is basically death for
> upstream.

It would be useful to add to 3.8 since Fedora 19 uses that version and it appears that will be use for quite some time.

*** Bug 722816 has been marked as a duplicate of this bug. ***

(In reply to comment #26)
> Milan, thank you for getting this fixed. Hopefully the 3.10.x users can confirm
> it.

I still see these crashes in evolution 3.10.3 .  I assume the patch has not yet been pushed into Fedora-20 updates; any idea when this will happen?  Is the patched version available?

The fix will be part of 3.10.4, to be released the next week. Fedora 20 package with the patch included does not exist (for 3.10.3).

Thanks for making bugfix releases so late in the cycle!

*** Bug 733193 has been marked as a duplicate of this bug. ***