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 651316 - Crash with Outgoing mail filters
Crash with Outgoing mail filters
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
3.0.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[filters]
: 653957 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-05-28 10:12 UTC by Gilboa Davara
Modified: 2011-08-04 14:43 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
evo patch (617 bytes, patch)
2011-06-03 11:49 UTC, Milan Crha 		committed Details | Review

Description Gilboa Davara 2011-05-28 10:12:29 UTC 
I've just upgraded my Fedora 14 machine to Fedora 15 (both x86_64) and I've started experiencing reproducible crashes every time I try to send an email.
Long story short, after a bit of playing around, I think I managed to find the source of the crash:
I'm using message filters to give evolution gmail like capabilities: Both
incoming and outgoing emails go through the same set of filters, and end up in
the same folders. (E.g. incoming and outgoing mails with
users@lists.fedoraproject.org in the recipient list both end-up in
Fedora-Users folder).

If I remove the outgoing mail filters, evolution doesn't crash.
If I restore them, evolution dies on the spot.

For additional information (callstack, etc): https://bugzilla.redhat.com/show_bug.cgi?id=708285
Please let me know if you want me to attach the callstack (etc) to this BZ.

- Gilboa
Comment 1 Matthew Barnes 2011-05-28 10:20:08 UTC 
The back trace in the downstream bug report is missing debugging symbols for evolution-data-server.  If you could post a new back trace here will full debugging symbols that would be helpful.
Comment 2 Milan Crha 2011-05-31 04:11:17 UTC 



+
Trace
    227327






Thread 1
          (Thread 0x7fd68bfff700 (LWP 30596))


    

  • 
#0
??

    • 

  • 
#1
open_folder

    
                at camel-filter-driver.c
                  line
                  1019

    

    • 

  • 
#2
do_copy

    
                at camel-filter-driver.c
                  line
                  473

    

    • 

  • 
#3
e_sexp_term_eval

    
                at e-sexp.c
                  line
                  731

    

    • 

  • 
#4
term_eval_begin

    
                at e-sexp.c
                  line
                  676

    

    • 

  • 
#5
e_sexp_term_eval

    
                at e-sexp.c
                  line
                  721

    

    • 

  • 
#6
e_sexp_eval

    
                at e-sexp.c
                  line
                  1568

    

    • 

  • 
#7
camel_filter_driver_filter_message

    
                at camel-filter-driver.c
                  line
                  1602

    

    • 

  • 
#8
mail_session_send_to_thread

    
                at e-mail-session-utils.c
                  line
                  480

    

    • 

  • 
#9
run_in_thread

    
                at gsimpleasyncresult.c
                  line
                  838

    

    • 

  • 
#10
io_job_thread

    
                at gioscheduler.c
                  line
                  181

    

    • 

  • 
#11
g_thread_pool_thread_proxy

    
                at gthreadpool.c
                  line
                  319

    

    • 

  • 
#12
g_thread_create_proxy

    
                at gthread.c
                  line
                  1897

    

    • 

  • 
#13
start_thread

    
                at pthread_create.c
                  line
                  305

    

    • 

  • 
#14
clone

    
                at ../sysdeps/unix/sysv/linux/x86_64/clone.S
                  line
                  115

    

    • 













Comment 3


Gilboa Davara





          2011-05-31 17:05:45 UTC
        



gdb output (sorry the ugly formatting..., let me know if I missed anything):

$ gdb /usr/bin/evolution
(gdb) r
....
Program received signal SIGSEGV, Segmentation fault.




+
Trace
    227333






Thread 140736930191104
          (LWP 22147)


    

  • 
#1
open_folder

    
                at camel-filter-driver.c
                  line
                  1019

    

    • 













Comment 4


Matthew Barnes





          2011-05-31 17:40:37 UTC
        



The "get_folder" function pointer was left NULL and open_folder() doesn't check for NULL before trying to invoke "get_folder".

CamelFilterDriver's API is pretty awful.  Things like "get_folder" should really be a virtual class method and we should be subclassing CamelFilterDriver in Evolution and overriding these methods in the subclass instead of having to install function pointers in each and every CamelFilterDriver instance.






Comment 5


Milan Crha





          2011-06-03 11:32:49 UTC
        



(In reply to comment #4)
> The "get_folder" function pointer was left NULL and open_folder() doesn't check
> for NULL before trying to invoke "get_folder".

This is not accurate. It was set to a correct function in e-mail-session.c:main_get_filter_driver, but e_mail_session_send_to() set it back to NULL. The get_folder_func and get_folder_data parameters in that function were always NULL. I'll remove them.






Comment 6


Milan Crha





          2011-06-03 11:49:08 UTC
        



Created attachment 189150 [details] [review]
evo patch

for evolution;

I thought I'll remove the get_folder_func/get_folder_data from e_mail_session_send_to() completely, but due to API change (it's a public API) I rather made the call to camel_filter_driver_set_folder_func() dependant also on the non-NULL get_folder_func pointer. It has the advantage that the caller can overwrite it, but if it will not, then the default get_folder function will be used.






Comment 7


Milan Crha





          2011-06-03 11:52:21 UTC
        



Created commit cd69158 in evo master (3.1.2+)
Created commit 62acb05 in evo gnome-3-0 (3.0.3+)






Comment 8


Gilboa Davara





          2011-06-04 15:13:56 UTC
        



Thanks!

Milan,
As Fedora bug (#708285) assignee, any chance that a fixed version will hit updates-testing before 3.0.3 mass-update?

- Gilboa






Comment 9


Christoph Wickert





          2011-06-05 16:34:42 UTC
        



Gilboa, I did a scratchbuild at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=3112020

I can confirm the patch works fine a outgoing filters are applied without crash.

Milan, are you fine with me pushing an update for Fedora or are there other plans?






Comment 10


Christoph Wickert





          2011-06-05 16:36:47 UTC
        



Sorry, wrong URL. The correct one is 
http://koji.fedoraproject.org/koji/taskinfo?taskID=3112019






Comment 11


Gilboa Davara





          2011-06-05 17:06:22 UTC
        



Tested.
Working like a champ, thanks!

- Gilboa






Comment 12


Milan Crha





          2011-06-06 08:48:40 UTC
        



(In reply to comment #9)
> Milan, are you fine with me pushing an update for Fedora or are there other
> plans?

I can add it in the update of 3.0.2-2, but I do not want to postpone it any further, it contains a critical crash, which people see more often than this. If Gilboa is fine, I would wait for the official 3.0.3 release.






Comment 13


Gilboa Davara





          2011-06-06 09:05:32 UTC
        



I'm a happy camper :)
Just to be certain, when 3.0.2-2 goes out, I should exclude it until 3.0.3 is released?

- Gilboa






Comment 14


Milan Crha





          2011-06-06 12:10:54 UTC
        



Yup, I understood from Christoph's build that he used 3.0.2-2 as a base package, thus you can safely avoid its update when it is released (hopefully the first half of this week). If you update through yum then it may skip it for you, because you've higher version right now.






Comment 15


Milan Crha





          2011-08-04 14:43:38 UTC
        



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