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 630697 - [imapx] evolution crash when moving a lot of messages
[imapx] evolution crash when moving a lot of messages
Status: RESOLVED OBSOLETE
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.10.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[imapx]
Depends on:
Blocks:
 
 
Reported: 2010-09-27 06:19 UTC by Yves-Alexis Perez
Modified: 2014-06-16 16:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.29/2.30


Description Yves-Alexis Perez 2010-09-27 06:19:53 UTC 
Hey,

I just experienced a (reproducible) crash when moving (a lot of) message from one folder to another. I'm not too sure it's related to the number (~1900) or to one message specifically.

Here's a backtrace:

+ Trace 223903

  • #0 __strstr_sse2
    at ../string/strstr.c line 63
  • #1 IA__g_strsplit
    at /scratch/build-area/glib2.0-2.24.2/glib/gstrfuncs.c line 2411
  • #2 imapx_parse_uids
    at camel-imapx-utils.c line 1616
  • #3 imapx_parse_status
    at camel-imapx-utils.c line 1696
  • #4 imapx_completion
    at camel-imapx-server.c line 1883
  • #5 imapx_step
    at camel-imapx-server.c line 1910
  • #6 parse_contents
    at camel-imapx-server.c line 4464
  • #7 imapx_parser_thread
    at camel-imapx-server.c line 4509
  • #8 g_thread_create_proxy
    at /scratch/build-area/glib2.0-2.24.2/glib/gthread.c line 1893
  • #9 start_thread
    at pthread_create.c line 300
  • #10 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #11 ?? 

Hope it's useful, I'll try moving the mails few by few.
Comment 1 Yves-Alexis Perez 2010-09-27 06:21:39 UTC 
Btw, it might be related to one specific mail since some of the mails are indeed moved to the destination folder (meaning trying to do the copy multiple time will have bad effects on the destination folder).
Comment 2 Milan Crha 2010-10-19 16:03:02 UTC 
It seems it got out of message uid list, encoded as a string. Though how that could happen I do not know. I tried to copy about 2K messages from one folder to another and it doesn't crash. This is with actual git master, which is just after 2.91.1 release, though I believe, with respect of imapx, it's almost the same as 2.32.0.
Comment 3 Kjetil Torgrim Homme 2010-11-04 02:08:37 UTC 
FWIW, I had the same problem with 2.30.3 from Fedora 13 (although I never made a stackstrace to verify completely).  The number of messages varied, sometimes I could move 2000 messages, but some times it would crash with as little as 1000.  With 2.32.0 from Fedora 14 I can reliably move 11000 messages.
Comment 4 Milan Crha 2012-07-12 06:46:58 UTC 
Similar downstream bug report from 3.2.3:
https://bugzilla.redhat.com/show_bug.cgi?id=839339

+ Trace 230500

Thread 1 (Thread 0x7f130540a700 (LWP 2939))

  • #0 __strstr_sse42
    at ../sysdeps/x86_64/multiarch/strstr.c line 179
  • #1 g_strsplit
    at gstrfuncs.c line 2427
  • #2 imapx_parse_uids
    at camel-imapx-utils.c line 1728
  • #3 imapx_parse_status
    at camel-imapx-utils.c line 1810
  • #4 imapx_completion
    at camel-imapx-server.c line 2057
  • #5 imapx_step
    at camel-imapx-server.c line 2086
  • #6 parse_contents
    at camel-imapx-server.c line 4934
  • #7 imapx_parser_thread
    at camel-imapx-server.c line 5001
  • #8 g_thread_create_proxy
    at gthread.c line 1962
  • #9 start_thread
    at pthread_create.c line 309
  • #10 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 115 






Comment 5


Matthew Barnes





          2013-08-22 17:06:13 UTC
        



Closing as OBSOLETE since the stack trace(s) are too old to be useful at this point.






Comment 6


Yves-Alexis Perez





          2013-08-22 17:57:12 UTC
        



(In reply to comment #5)
> Closing as OBSOLETE since the stack trace(s) are too old to be useful at this
> point.

Don't take it personnaly, I do that kind of things myself, but still, that comment just make me feel like “well, taking care of the bug three years ago, the stack traces would not have been so old”.






Comment 7


Milan Crha





          2014-06-12 06:42:48 UTC
        



I'm reopening this, due to another downstream bug report being reported in 3.10.4:
https://bugzilla.redhat.com/show_bug.cgi?id=1108363

Version-Release number of selected component:
evolution-3.10.4-2.fc20

Additional info:
reporter:       libreport-2.2.2
backtrace_rating: 4
cmdline:        evolution
crash_function: strstr
executable:     /usr/bin/evolution
kernel:         3.14.5-200.fc20.x86_64

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




+
Trace
    233689






Thread 1
          (Thread 0x7ff091b3b700 (LWP 7503))


    

  • 
#0
__strstr_sse42

    
                at ../sysdeps/x86_64/multiarch/strstr.c
                  line
                  175

    

    • 

  • 
#1
g_strsplit

    
                at gstrfuncs.c
                  line
                  2277

    

    • 

  • 
#2
imapx_parse_uids

    
                at camel-imapx-utils.c
                  line
                  2004

    

    • 

  • 
#3
imapx_parse_status_copyuid

    
                at camel-imapx-utils.c
                  line
                  2072

    

    • 

  • 
#4
imapx_parse_status

    
                at camel-imapx-utils.c
                  line
                  2268

    

    • 

  • 
#5
imapx_completion

    
                at camel-imapx-server.c
                  line
                  2878

    

    • 

  • 
#6
imapx_step

    
                at camel-imapx-server.c
                  line
                  2922

    

    • 

  • 
#7
imapx_parse_contents

    
                at camel-imapx-server.c
                  line
                  6873

    

    • 

  • 
#8
imapx_parser_thread

    
                at camel-imapx-server.c
                  line
                  6944

    

    • 

  • 
#9
g_thread_proxy

    
                at gthread.c
                  line
                  798

    

    • 

  • 
#10
start_thread

    
                at pthread_create.c
                  line
                  309

    

    • 

  • 
#11
clone

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

    

    • 













Comment 8


Milan Crha





          2014-06-16 16:11:23 UTC
        



I tried to reproduce this with current git master (to be 3.13.3 development version), which is pretty much the same as 3.12.x in this part, and I was able to successfully move/copy over 4000 messages from one folder to another on one IMAPx account. I found couple memory leaks during testing, but nothing else here.