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 723345 - [abrt] Crash under nntp_stream_fill()
[abrt] Crash under nntp_stream_fill()
Status: RESOLVED OBSOLETE
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.8.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2014-01-31 07:00 UTC by Milan Crha
Modified: 2018-12-11 17:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Milan Crha 2014-01-31 07:00:32 UTC
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1059740

Description of problem:
I subscribed to two more NNTP groups and then added them to a vfolder.

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

Additional info:
reporter:       libreport-2.1.10
backtrace_rating: 4
cmdline:        evolution
crash_function: memcpy
executable:     /usr/bin/evolution
kernel:         3.11.9-200.fc19.x86_64


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

Thread 22 (Thread 0x7f5c9bf4a700 (LWP 29113))

  • #0 fsync
    at ../sysdeps/unix/syscall-template.S line 81
  • #1 full_fsync
    at sqlite3.c line 26497
  • #2 unixSync
    at sqlite3.c line 26586
  • #3 call_old_file_Sync
    at camel-db.c line 68
  • #4 sync_request_thread_cb
    at camel-db.c line 94
  • #5 g_thread_pool_thread_proxy
    at gthreadpool.c line 309
  • #6 g_thread_proxy
    at gthread.c line 798
  • #7 start_thread
    at pthread_create.c line 308
  • #8 clone
    from /lib64/libc.so.6

Thread 1 (Thread 0x7f5ca2ff3700 (LWP 29073))

  • #0 __memcpy_sse2
    from /lib64/libc.so.6
  • #1 memcpy
    at /usr/include/bits/string3.h line 51
  • #2 nntp_stream_fill
    at camel-nntp-stream.c line 79
  • #3 camel_nntp_stream_line
    at camel-nntp-stream.c line 293
  • #4 add_range_xover
    at camel-nntp-summary.c line 230
  • #5 camel_nntp_summary_check
    at camel-nntp-summary.c line 529
  • #6 camel_nntp_folder_selected
    at camel-nntp-folder.c line 161
  • #7 camel_nntp_command
    at camel-nntp-store.c line 2246
  • #8 nntp_folder_refresh_info_online
    at camel-nntp-folder.c line 199
  • #9 disco_refresh_info_sync
    at camel-disco-folder.c line 316
  • #10 camel_folder_refresh_info_sync
    at camel-folder.c line 4147
  • #11 camel_nntp_folder_new
    at camel-nntp-folder.c line 882
  • #12 disco_store_get_folder_sync
  • #13 camel_store_get_folder_sync
  • #14 e_mail_session_uri_to_folder_sync
  • #15 refresh_folders_exec
    at mail-send-recv.c line 1044
  • #16 mail_msg_proxy
    at mail-mt.c line 426
  • #17 g_thread_pool_thread_proxy
    at gthreadpool.c line 309
  • #18 g_thread_proxy
    at gthread.c line 798
  • #19 start_thread
    at pthread_create.c line 308
  • #20 clone
    from /lib64/libc.so.6

Comment 1 Brian J. Murrell 2014-01-31 12:59:24 UTC
I wonder if you can provide any advise.  Since this segfault happens during startup even I am completely unable to use evolution.
Comment 2 Milan Crha 2014-02-03 09:31:37 UTC
Are you able to reproduce this crash reliably? I was not, unfortunately. What is your evolution version? If this is reliable, then it might depend on actual NNTP account state, like what messages are to be downloaded, thus I would be interested in your local cache for the NNTP account, together with the account setting, if it's a public server, without password. You can find the account setting in ~/.config/evolution/sources, basically all .source files which contain 'nntp' in it. The local cache is stored at ~/.cache/evolution/mail/<nntp-account-uid>, where nntp-account-uid is the file's name part of the .source files (the .source filename is "<nntp-account-uid>.source"). The <nntp-account-uid> string might be also included in other .source files (up to 2), where one is used for sending.

One option to get past the crash is to start evolution in offline (evolution --offline), or even unplug the computer from the Internet completely, and disable/remove the NNTP account - of course, you'll lose the NNTP part of evolution, but you'll be able to run it. Getting rid of above-mentioned .source files, or the NNTP cache might do the trick too, I guess, just please do not delete them, if they lead to a reproducer.
Comment 3 Brian J. Murrell 2014-02-03 12:04:07 UTC
(In reply to comment #2)
> Are you able to reproduce this crash reliably?

Hrm.  I thought for sure my answer to this was going to be "of course" since I have not been using for a couple of days given that it crashed several times in a row when I originally reported the bug.

So I was surprised when I started it up this morning just to make sure it was not going to make a liar out of me when I reported that and then lo and behold, it's working.

> What
> is your evolution version?

evolution-3.8.5-2.fc19

> One option to get past the crash is to start evolution in offline (evolution
> --offline), or even unplug the computer from the Internet completely, and
> disable/remove the NNTP account

Ahhh.  Great idea.  I had not thought of that.  I will try to keep that in mind for next time.

Thanks much!
Comment 4 Milan Crha 2014-02-03 16:24:51 UTC
(In reply to comment #3)
> So I was surprised when I started it up this morning just to make sure it was
> not going to make a liar out of me when I reported that and then lo and behold,
> it's working.

So it works for you the same way as for me, it crashes couple times, but once I eventually try to figure out what is wrong it starts working "properly" (not crashing). I'm pretty sure the fix will be small, it might be just about some overlook in reference counting, but getting it is so hard for me that I cannot figure out the reason of the crash.
Comment 5 Brian J. Murrell 2014-02-03 16:27:09 UTC
(In reply to comment #4)
> 
> So it works for you the same way as for me, it crashes couple times, but once I
> eventually try to figure out what is wrong it starts working "properly" (not
> crashing).

I guess that's the case.  I suppose I was just not persistent enough the first time I saw this a couple of times.

> I'm pretty sure the fix will be small, it might be just about some
> overlook in reference counting,

Yeah.

> but getting it is so hard for me that I cannot
> figure out the reason of the crash.

I will try to gather some data after the initial crash if I see this again.
Comment 6 Milan Crha 2018-12-11 17:00:15 UTC
Thanks for a bug report. I'm closing this as obsolete, but feel free to reopen or comment in case you can reproduce with the current 3.30.x stable series.