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 739341 - Program received signal SIGSEGV, Segmentation fault. 0x00007ffff1917461 in setAtkStateSetFromCoreObject (stateSet=0x38dbba0, coreObject=0x7fff80101a50) at Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp:797
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff1917461 in se...
Status: RESOLVED INCOMPLETE
Product: evolution
Classification: Applications
Component: Mailer
3.12.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2014-10-29 09:56 UTC by Ankur Sinha (FranciscoD)
Modified: 2018-10-10 07:12 UTC
See Also:
GNOME target: ---
GNOME version: 3.13/3.14


Attachments
Complete multi thread backtrace (53.80 KB, text/x-log)
2014-10-29 09:56 UTC, Ankur Sinha (FranciscoD)
Details
Offending e-mail (12.30 KB, application/mbox)
2014-10-30 10:56 UTC, Ankur Sinha (FranciscoD)
Details
reproducer email (16.67 KB, text/plain)
2014-11-05 07:38 UTC, Milan Crha
Details

Description Ankur Sinha (FranciscoD) 2014-10-29 09:56:15 UTC
Created attachment 289571 [details]
Complete multi thread backtrace

[asinha@CS-as14aho-2  Dropbox]$ rpm -qa \*evolution\*
evolution-data-server-3.12.7.1-1.fc21.x86_64
evolution-debuginfo-3.12.7-1.fc21.x86_64
evolution-3.12.7-1.fc21.x86_64
evolution-ews-3.12.7-1.fc21.x86_64
evolution-data-server-debuginfo-3.12.7.1-1.fc21.x86_64
evolution-help-3.12.7-1.fc21.noarch

Can be reproduced reliably with a specific e-mail. The e-mail looks quite normal. I can try and provide it if required.

- start evo
- click on this mail
- watch evo crash

Complete multithreaded trace attached.
Comment 1 Ankur Sinha (FranciscoD) 2014-10-29 10:05:47 UTC
Abrt filed this I think: https://bugzilla.redhat.com/show_bug.cgi?id=1158398
Comment 2 Milan Crha 2014-10-30 06:51:07 UTC
Thanks for a bug report. Better to paste backtraces inline, to be able to search for duplicates easily. If you have a message which reproduces the crash reliably, then it'll definitely help to investigate the issue. Just disable preview (Ctrl+M) in the offending folder, selected the message, right-click it and choose Save as mbox. Remove any private information in it, like by editing the text and censoring it with 'x'. The crash happened in the webkit code, what is your current webkitgtk3 version, please?

Thread 1 (Thread 0x7ffff7f9ea40 (LWP 29946))

  • #0 setAtkStateSetFromCoreObject
    at Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp line 797
  • #1 webkitAccessibleRefStateSet
    at Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp line 923
  • #2 children_changed_event_listener
    at event.c line 1079
  • #3 signal_emit_unlocked_R
    at gsignal.c line 3519
  • #4 g_signal_emit_valist
    at gsignal.c line 3309
  • #5 g_signal_emit_by_name
    at gsignal.c line 3405
  • #6 WebCore::AXObjectCache::getOrCreate
    at Source/WebCore/accessibility/AXObjectCache.cpp line 354
  • #7 WebCore::AccessibilityObject::parentObjectUnignored
    at Source/WebCore/accessibility/AccessibilityObject.cpp line 368
  • #8 WebCore::AXObjectCache::attachWrapper
    at Source/WebCore/accessibility/atk/AXObjectCacheAtk.cpp line 79
  • #9 WebCore::AXObjectCache::getOrCreate
    at Source/WebCore/accessibility/AXObjectCache.cpp line 419
  • #10 WebCore::Document::implicitClose
    at Source/WebCore/dom/Document.cpp line 2470
  • #11 WebCore::FrameLoader::checkCompleted
    at Source/WebCore/loader/FrameLoader.cpp line 844
  • #12 WebCore::FrameLoader::finishedParsing
    at Source/WebCore/loader/FrameLoader.cpp line 768
  • #13 WebCore::Document::finishedParsing
    at Source/WebCore/dom/Document.cpp line 4456
  • #14 WebCore::HTMLConstructionSite::finishedParsing
    at Source/WebCore/html/parser/HTMLConstructionSite.cpp line 392
  • #15 WebCore::HTMLTreeBuilder::finished
    at Source/WebCore/html/parser/HTMLTreeBuilder.cpp line 3025
  • #16 WebCore::HTMLDocumentParser::end
    at Source/WebCore/html/parser/HTMLDocumentParser.cpp line 439
  • #17 WebCore::HTMLDocumentParser::attemptToRunDeferredScriptsAndEnd
    at Source/WebCore/html/parser/HTMLDocumentParser.cpp line 450
  • #18 WebCore::HTMLDocumentParser::prepareToStopParsing
    at Source/WebCore/html/parser/HTMLDocumentParser.cpp line 165
  • #19 WebCore::HTMLDocumentParser::finish
    at Source/WebCore/html/parser/HTMLDocumentParser.cpp line 490
  • #20 WebCore::DocumentWriter::end
    at Source/WebCore/loader/DocumentWriter.cpp line 248
  • #21 WebCore::DocumentLoader::finishedLoading
    at Source/WebCore/loader/DocumentLoader.cpp line 440
  • #22 WebCore::CachedResource::checkNotify
    at Source/WebCore/loader/cache/CachedResource.cpp line 332
  • #23 WebCore::CachedRawResource::finishLoading
    at Source/WebCore/loader/cache/CachedRawResource.cpp line 94
  • #24 WebCore::SubresourceLoader::didFinishLoading
    at Source/WebCore/loader/SubresourceLoader.cpp line 309
  • #25 WebCore::readCallback
    at Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp line 1339
  • #26 async_ready_callback_wrapper
    at ginputstream.c line 523
  • #27 g_task_return_now
    at gtask.c line 1077
  • #28 complete_in_idle_cb
    at gtask.c line 1086
  • #29 g_main_dispatch
    at gmain.c line 3111
  • #30 g_main_context_dispatch
    at gmain.c line 3710
  • #31 g_main_context_iterate
    at gmain.c line 3781
  • #32 g_main_loop_run
    at gmain.c line 3975
  • #33 gtk_main
    at gtkmain.c line 1207
  • #34 main
    at main.c line 685

Comment 3 Ankur Sinha (FranciscoD) 2014-10-30 10:56:35 UTC
Created attachment 289641 [details]
Offending e-mail

webkitgtk3-devel-2.4.7-1.fc21.x86_64
webkitgtk3-2.4.7-1.fc21.x86_64
webkitgtk-2.4.7-1.fc21.x86_64
webkitgtk4-2.6.2-1.fc21.x86_64
webkitgtk3-debuginfo-2.4.6-1.fc21.x86_64

Sorry about the stack trace Milan - they're generally quite long and I'm never sure if I should paste them or attach them :(
Comment 4 Ankur Sinha (FranciscoD) 2014-10-30 11:00:15 UTC
When I import the attached mbox message, it doesn't crash evo. If it doesn't help you debug, I can maybe send you the unedited mbox message privately if required, Milan. Or I can attach it to the rhbz and you can mark it as private.
Comment 5 Milan Crha 2014-10-30 19:14:32 UTC
Hmm, works for me without crash too. Preferably send the message as stored on the disk (~/.cache/evolution/mail/<account-uid>/... or ~/.local/share/evolution/mail/....) to my email, with the bug number/link in the subject, thus I don't overlook it. I will try whether the verbatim copy will cause the crash and then let you know. You can find the message by Mesasge-ID header, which the attached has:
   <D3B111151A167849A02B58E9BB1863D90197AAB4F887@UH-MAILSTOR.herts.ac.uk>
Comment 6 Ankur Sinha (FranciscoD) 2014-10-31 09:53:31 UTC
(In reply to comment #5)
> Hmm, works for me without crash too. Preferably send the message as stored on
> the disk (~/.cache/evolution/mail/<account-uid>/... or
> ~/.local/share/evolution/mail/....) to my email, with the bug number/link in
> the subject, thus I don't overlook it. I will try whether the verbatim copy
> will cause the crash and then let you know. You can find the message by
> Mesasge-ID header, which the attached has:
>    <D3B111151A167849A02B58E9BB1863D90197AAB4F887@UH-MAILSTOR.herts.ac.uk>

Sent. 

I couldn't get evolution to import the file to test, though. I right clicked on the file in nautilus and used "open with evolution", but nothing seemed to happen (even after adding an .mbox extension).

Oh, but when I try to see the mail I sent you, evolution crashes if I don't disable the preview mode - so that sort of confirms it. Hopefully evo will crash when you try to see the mail too :)
Comment 7 Milan Crha 2014-10-31 10:51:00 UTC
Thanks, the message is "missing" a "From email" line as its first line, it's a limitation of the import. I imported it and running webkitgtk3 2.2.5 shows the message correctly, but when I open it with webkigtk3 2.4.6 or 2.4.7, then it crashes. I run it under valgrind and it claims a use of some invalid pointer just before the crash, thus it looks like a bug in webkit on the first look. I'll investigate further (when 2.4.6 will be built on my main machine). It can be also something with connection to gtk. I'll know more later.
Comment 8 Milan Crha 2014-10-31 18:57:03 UTC
Hrm, locally built webkigtk3-2.4.7 with locally built atk-2.14.0, glib-2.42.0, glib-networking-2.42.0, gtk+-3.14.3 (some outdated git clone, right after 3.14.2 release) and pango-1.36.8 under Fedora 20 environment doesn't reproduce the crash. The other library versions are pretty much the same as I have in my Fedora 21 machine, where I can reproduce the crash. That makes me think that the issue is somewhere else, probably in another library used by webkit (I'm plain guessing here).

Tomas, could you look on this, please? It's crashing in the webkit code, maybe you noticed something similar earlier. If Ankur will be fine, I'll give you the reproducer message as sent by Ankur to me. Only note thatI tried to reproduce this under rawhide, with no luck. I could reproduce on Fedora 21 though.
Comment 9 Ankur Sinha (FranciscoD) 2014-11-01 11:13:12 UTC
(In reply to comment #8) If Ankur will be fine, I'll give you the
> reproducer message as sent by Ankur to me. 

Sure. The mail doesn't have any security critical information - it just has peoples names :)
Comment 10 Milan Crha 2014-11-05 07:38:19 UTC
Created attachment 290001 [details]
reproducer email

This is a sanitized version of the email, which also reproduces the crash on Fedora 21. It seems to be related to the To filed, where are quite many people added.
Comment 11 Christian Stadelmann 2014-12-10 21:52:18 UTC
I ran into the same crash (according to ABRT/libreport, see downstreams bug report) with a very different email. When opening a specific email message evolution reliably crashes. This can be reproduced. It happens to one of two exactly identical emails (diff is empty). The only difference is the filename and read/unread state. Opening the unread email works, opening the read email crashes Evolution. This email contains HTML content only, no ordinary text. Shall I send you the mail to your email address?
Comment 12 Milan Crha 2014-12-11 06:38:37 UTC
If you get the same backtrace then it's not needed, the reproducer is attached above. The problem is to figure out what's going wrong, while it looks like a webkit issue, not necessarily evolution's.
Comment 13 Christian Stadelmann 2015-01-18 13:42:03 UTC
I got another email causing this crash. When trying to reproduce the bug I found this strange behavior:

1. When running evolution with mail component and email preview open, evolution crashes when opening the e-mail. This time it affects both a read and an unread email.
2. When disabling email preview in the mail component, evolution does not crash any more when selecting the email. Even double-clicking on the email does not crash evolution.

I doubt this is related to the "To" field (as in comment #10) since I only have one single recipient (~40 characters) without any special characters whatsoever (subset of us-ascii: latin letters plus <, >, @ and space).
This time again I did have two identical emails with different status (one was read, another one unread) before the bug happened.
Comment 14 Christian Stadelmann 2018-10-09 22:52:13 UTC
I have not seen this crash in a few years. Also, with the original E-Mail I cannot reproduce it either. This bug report could be closed IMHO.
Comment 15 Milan Crha 2018-10-10 07:12:14 UTC
Thanks for the update. I'm closing this.