Red Hat Bugzilla – Bug 1247401
[abrt] evolution: operator->(): evolution killed by SIGSEGV
Last modified: 2016-07-19 13:13:05 EDT
Version-Release number of selected component:
runlevel: N 5
Thread no. 1 (10 frames)
#0 operator-> at Source/WTF/wtf/OwnPtr.h:56
#1 removeFloat at Source/WebCore/rendering/RootInlineBox.h:157
#2 WebCore::RenderBlockFlow::removeFloatingObject at Source/WebCore/rendering/RenderBlockFlow.cpp:2117
#3 WebCore::RenderBlockFlow::markAllDescendantsWithFloatsForLayout at Source/WebCore/rendering/RenderBlockFlow.cpp:2545
#4 WebCore::RenderBox::removeFloatingOrPositionedChildFromBlockLists at Source/WebCore/rendering/RenderBox.cpp:260
#5 WebCore::RenderElement::removeChildInternal at Source/WebCore/rendering/RenderElement.cpp:598
#6 WebCore::RenderElement::removeChild at Source/WebCore/rendering/RenderElement.cpp:520
#7 WebCore::RenderObject::removeFromParent at Source/WebCore/rendering/RenderObject.cpp:187
#8 WebCore::RenderObject::willBeDestroyed at Source/WebCore/rendering/RenderObject.cpp:1841
#9 WebCore::RenderElement::willBeDestroyed at Source/WebCore/rendering/RenderElement.cpp:1023
Created attachment 1056770 [details]
Created attachment 1056771 [details]
Created attachment 1056772 [details]
Created attachment 1056773 [details]
Created attachment 1056774 [details]
Created attachment 1056775 [details]
Created attachment 1056776 [details]
Created attachment 1056777 [details]
Created attachment 1056778 [details]
Created attachment 1056779 [details]
Created attachment 1056780 [details]
Created attachment 1056781 [details]
Created attachment 1056782 [details]
Thanks for a bug report. The crash happened deep inside webkit, thus I move this there. I guess this crashed when you were replying to certain message. Are you able to reproduce this reliably with it? If yes, would it possible to share the message for testing purposes, please?
No, its not reliable. Very often it just crashes when I'm not doing anything in particular to Evolution: possibly a shift in focus causes these.
One crash was reliable though: attempting to reply to an e-mail sent from NZ that was simply a link to a newspaper article but sent by the news site when requested by my cousin crashed reliably and immediately when I attempted to send comments to my cousin. Unfortunately, I binned that e-mail but I've asked him to resend it, or a similar link that I can forward to you.
BTW, I have some other issues with Evolution:
1) One that really irritates me is that I can only scroll a message using the cursor (arrow) keys when its first opened OR if I've just clicked on the heading area that shows sender and subject. If focus is lost and regained or if I click on the message body text the cursor key scrolling is disabled until the heading area is again clicked. This is really annoying if its part of a long message, e.g. a logwatch report, because I have to scroll back to the top of the message using the scroll bars, click the header and then scroll back to where I was. Every other application I use restores focus AND re-enables cursor scrolling if I click anywhere inside the text area, so why can't Evolution do the same. This also leads on to point (2)
2) I use the XFCE with the Clearlooks Classic appearance selected because that gives me scroll bars with the 'line at a time' buttons enabled at each end of scrollbars. I work with a lot of large text files (Java source code, etc) and these are almost impossible to navigate without these buttons because buttonless scrollbars smallest movement steps are too big to be useful with a really large file.
However, I can't do this with Evolution (hence my insistence on using arrow keys) because the latest versions, unlike just about every other application, don't use XFCE's look & feel as defined by the selected appearance. This link needs to be restored.
3) Why does my mouse cursor become semi-disconnected from the scroll bar? This happens more often than not. The symptom is that, instead of scrolling as fast as I move the mouse, the scrollbar suddenly decides to scroll at about half speed while the mouse shoots on ahead.
If I raise bugs about these points, will the Evolution team accept them?
Here's the e-mail that caused the crash. As you can see its a single piece of body text (no MIME at all) but the body is utf-8 text that has been base64 encoded to be sent. I haven't decoded it, but know that it contains a link to:
which is a reference to the newspaper article I was being asked to read.
Created attachment 1057175 [details]
Replying to the attached e-mail caused Evolution to crash.
(In reply to Martin Gregorie from comment #17)
> Created attachment 1057175 [details]
> Replying to the attached e-mail caused Evolution to crash.
Thanks, I moved this part upstream as:
(In reply to Martin Gregorie from comment #15)
> 1) One that really irritates me is that I can only scroll a message using
> the cursor (arrow) keys when its first opened OR if I've just clicked on the
> heading area that shows sender and subject. ...
I'm not sure I follow, is it about View->Caret Mode (F7) menu option, which you've checked? Even though it works fine here, either it is checked or it isn't checked, but I use MATE, not XFCE. I know they do some odd things on focus change, like the complete style change causes gtk3 to redraw the content, which has some other consequences.
> 2) ...
> However, I can't do this with Evolution (hence my insistence on using arrow
> keys) because the latest versions, unlike just about every other
> application, don't use XFCE's look & feel as defined by the selected
> appearance. This link needs to be restored.
This is all about gtk3, evolution uses it and it does what it likes to do. With "line at a time", do you mean that the scroll bars are hidden when the mouse is not above the are? That's a new behaviour of gtk3 and can be turned off by exporting GTK_OVERLAY_SCROLLING=0 environment variable.
> 3) Why does my mouse cursor become semi-disconnected from the scroll bar?
> This happens more often than not. The symptom is that, instead of scrolling
> as fast as I move the mouse, the scrollbar suddenly decides to scroll at
> about half speed while the mouse shoots on ahead.
Also gtk3 thing, sounds to me like another new feature of it, described here:
> I'm not sure I follow, is it about View->Caret Mode (F7) menu option, which
> you've checked? Even though it works fine here, either it is checked or it
> isn't checked,
Yes, it is connected with the Carat mode (what a non-obvious name to use!),
but my real objection is that Evolution (and Firefox) don't follow L&F when the desktop appearance changes. If thats a 'feature' of GTK3, then I'd call it a bug because surely the whole purpose of changing the desktop skin (XFCE's 'appearance' control) is to apply consistent changes to colour assignments, scroll bar L&F, etc. across all applications. Doing anything else leaves us with a dogs breakfast of behaviours and appearances typical of Windows 95 applications.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.