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 740297 - [abrt] [SMTP] Crash when sending two messages at once
[abrt] [SMTP] Crash when sending two messages at once
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.12.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 744710 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-11-18 05:22 UTC by Milan Crha
Modified: 2015-02-26 10:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Valgrind log (47.45 KB, text/plain)
2014-12-09 19:01 UTC, Milan Bouchet-Valat
Details

Description Milan Crha 2014-11-18 05:22:49 UTC
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1164795

Version-Release number of selected component:
evolution-3.12.8-1.fc21

Additional info:
reporter:       libreport-2.3.0
backtrace_rating: 4
cmdline:        evolution mailto:?attach=file:///home/gajendra/Desktop/Software%20Testing%20File.pdf
crash_function: camel_stream_buffer_gets
executable:     /usr/bin/evolution
kernel:         3.17.3-300.fc21.x86_64

Core was generated by `evolution mailto:?attach=file:///home/gajendra/Desktop/Software%20Testing%20Fil'.
Program terminated with signal SIGSEGV, Segmentation fault.

Thread 1 (Thread 0x7fe249df5700 (LWP 9052))

  • #0 camel_stream_buffer_gets
    at camel-stream-buffer.c line 438
  • #1 camel_stream_buffer_read_line
    at camel-stream-buffer.c line 499
  • #2 smtp_mail
    at camel-smtp-transport.c line 1366
  • #3 smtp_transport_send_to_sync
    at camel-smtp-transport.c line 766
  • #4 transport_send_to_thread
    at camel-transport.c line 148
  • #5 service_task_thread
    at camel-service.c line 364
  • #6 g_task_thread_pool_thread
    at gtask.c line 1215
  • #7 g_thread_pool_thread_proxy
    at gthreadpool.c line 307
  • #8 g_thread_proxy
    at gthread.c line 764
  • #9 start_thread
    at pthread_create.c line 310
  • #10 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 109

Comment 1 Milan Crha 2014-11-18 14:39:26 UTC
This looks like a memory corruption, the function doesn't check for a pointer validity, thus it accessed a private member which is out of range (the other is, the one where it crashed was a deference of NULL). I do not know what to look at, unless a reproducer would be found.

A similar bug, in a sense of "after sending a message" is described at:
https://bugzilla.redhat.com/show_bug.cgi?id=1158055
Comment 2 Milan Bouchet-Valat 2014-12-09 19:01:11 UTC
Created attachment 292406 [details]
Valgrind log

I got this crash twice in a row (i.e. right after restarting Evo, when trying to send the same two messages again). It might have something to do with trying to send two messages at the same time.

The second time I restarted Evo, I run it in Valgrind. Unfortunately the crash did not happen, maybe because it's very hard to send two messages at the same time under the slow Valgrind. Anyway I'm attaching the log, in case there's something useful.
Comment 3 Milan Crha 2014-12-10 06:56:00 UTC
Thanks for the update. The valgrind log doesn't show anything related, but the detail of sending two messages at the same time might be it. I'll test it here and get back to you when I know more.
Comment 4 Milan Crha 2014-12-10 07:29:49 UTC
I can confirm the crash, when sending two messages at once. The SMTP provider is not meant to be used this way. It'll require some nontrivial changes, either on the evolution side (in the composer), or on the SMTP provider side. The thing is that the send in composer doesn't use a global queue, while with the old behaviour of sending messages through Outbox created the queue as a side effect.
Comment 5 Milan Crha 2014-12-10 09:29:38 UTC
Dealing with this on the evolution-data-server side would be too complicated, especially when evolution itself is driving the connection state of the transport service, thus I made the change on the evolution side, by "locking" the service usage to have a serialized queue, rather than the parallel.

Created commit ab45f3f in evo master (3.13.9+) [1]
Created commit f2a6072 in evo evolution-3-12 (3.12.10+)

[1] https://git.gnome.org/browse/evolution/commit/?id=ab45f3f
    The 3.12 patch doesn't have the new localized string.
Comment 6 Milan Crha 2015-02-26 10:53:03 UTC
*** Bug 744710 has been marked as a duplicate of this bug. ***