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 712169 - set trash to real folder => crash
set trash to real folder => crash
Status: RESOLVED DUPLICATE of bug 704663
Product: evolution
Classification: Applications
Component: Mailer
3.10.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2013-11-12 18:01 UTC by Stanislav Brabec
Modified: 2013-11-15 19:22 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
evolution backtrace (33.03 KB, text/plain)
2013-11-12 18:01 UTC, Stanislav Brabec 		Details

Description Stanislav Brabec 2013-11-12 18:01:44 UTC 
Created attachment 259685 [details]
evolution backtrace

I decided to change evolution preferences, and set a real trash folder "Koš" for one of my accounts (the same string uses evolution i Czech for the name of the virtual folder; the folder already existed and was not empty, and also folder named "Trash" existed before (and was empty)).

It caused evolution crash. The operation was completed anyway and next time evolution used a real trash folder. I did not try to reproduce it.

openSUSE 13.1 x86_64
evolution-3.10.1
evolution-data-server-3.10.1

Program terminated with signal SIGFPE, Arithmetic exception.

+ Trace 232750

  • #0 g_hash_table_lookup_node
    at ghash.c line 371 






Comment 1


Matthew Barnes





          2013-11-13 21:40:47 UTC
        



Hmm, can't tell from the backtrace why this would have crashed.

The crashing statement in ghash.c is:

  node_index = hash_value % hash_table->mod

As far as Evolution goes, I can see that:

  The hash key (a CamelStore pointer) appears to be valid.  The pointer value
  is non-zero and em_folder_tree_model_add_store() has a CAMEL_IS_STORE check
  and the beginning of the function.

  The hash table itself is only destroyed along with the EMFolderTreeModel,
  and EMFolderTreeModel is a singleton which lasts for the entire duration of
  the Evolution session.

Marking this NEEDINFO since I can't really do anything with this atm.






Comment 2


Stanislav Brabec





          2013-11-14 16:56:03 UTC
        



I just tested to disable real trash folder and then re-enable.

The crash is reproducible on my machine!

Here is a more detailed backtrace. I will store the backtrace of the current crash for some time, so if you need to peek variables, I can provide more gdb data.






+
Trace
    232771






Thread 1
          (Thread 0x7f270627ea40 (LWP 25146))


    

  • 
#0
g_hash_table_lookup_node

    
                at ghash.c
                  line
                  371

    

    • 

  • 
#1
g_hash_table_insert_internal

    
                at ghash.c
                  line
                  1153

    

    • 

  • 
#2
em_folder_tree_model_add_store

    
                at em-folder-tree-model.c
                  line
                  1157

    

    • 

  • 
#3
g_closure_invoke

    
                at gclosure.c
                  line
                  777

    

    • 

  • 
#4
signal_emit_unlocked_R

    
                at gsignal.c
                  line
                  3586

    

    • 

  • 
#5
g_signal_emit_valist

    
                at gsignal.c
                  line
                  3330

    

    • 

  • 
#6
g_signal_emit

    
                at gsignal.c
                  line
                  3386

    

    • 

  • 
#7
store_emit_folder_info_stale_cb

    
                at camel-store.c
                  line
                  223

    

    • 

  • 
#8
g_main_dispatch

    
                at gmain.c
                  line
                  3065

    

    • 

  • 
#9
g_main_context_dispatch

    
                at gmain.c
                  line
                  3641

    

    • 

  • 
#10
g_main_context_iterate

    
                at gmain.c
                  line
                  3712

    

    • 

  • 
#11
g_main_loop_run

    
                at gmain.c
                  line
                  3906

    

    • 

  • 
#12
gtk_main

    
                at gtkmain.c
                  line
                  1158

    

    • 

  • 
#13
main

    
                at main.c
                  line
                  683

    

    • 













Comment 3


Milan Crha





          2013-11-15 19:22:59 UTC
        



I suppose this is the same as bug #704663 (which is for 3.8), thus I move this under it.

*** This bug has been marked as a duplicate of bug 704663 ***