Bug 1247401 - [abrt] evolution: operator->(): evolution killed by SIGSEGV
[abrt] evolution: operator->(): evolution killed by SIGSEGV
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: webkitgtk3 (Show other bugs)
22
i686 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
https://retrace.fedoraproject.org/faf...
abrt_hash:e31ae99ea09ddd9357e08577a2e...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-07-27 18:41 EDT by Martin Gregorie
Modified: 2016-07-19 13:13 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 13:13:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (65.22 KB, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: build_ids (11.25 KB, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: cgroup (177 bytes, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: core_backtrace (16.69 KB, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: dso_list (27.73 KB, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: environ (3.81 KB, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: limits (1.29 KB, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: maps (84.12 KB, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: mountinfo (3.17 KB, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: namespaces (85 bytes, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: open_fds (3.83 KB, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: proc_pid_status (824 bytes, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
File: var_log_messages (308 bytes, text/plain)
2015-07-27 18:41 EDT, Martin Gregorie
no flags Details
Replying to the attached e-mail caused Evolution to crash. (4.75 KB, text/plain)
2015-07-28 19:02 EDT, Martin Gregorie
no flags Details

  None (edit)
Description Martin Gregorie 2015-07-27 18:41:16 EDT
Version-Release number of selected component:
evolution-3.16.4-2.fc22

Additional info:
reporter:       libreport-2.6.1
backtrace_rating: 4
cmdline:        evolution
crash_function: operator->
executable:     /usr/bin/evolution
global_pid:     2087
kernel:         4.0.8-300.fc22.i686+PAE
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
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
Comment 1 Martin Gregorie 2015-07-27 18:41:22 EDT
Created attachment 1056770 [details]
File: backtrace
Comment 2 Martin Gregorie 2015-07-27 18:41:23 EDT
Created attachment 1056771 [details]
File: build_ids
Comment 3 Martin Gregorie 2015-07-27 18:41:24 EDT
Created attachment 1056772 [details]
File: cgroup
Comment 4 Martin Gregorie 2015-07-27 18:41:26 EDT
Created attachment 1056773 [details]
File: core_backtrace
Comment 5 Martin Gregorie 2015-07-27 18:41:28 EDT
Created attachment 1056774 [details]
File: dso_list
Comment 6 Martin Gregorie 2015-07-27 18:41:29 EDT
Created attachment 1056775 [details]
File: environ
Comment 7 Martin Gregorie 2015-07-27 18:41:30 EDT
Created attachment 1056776 [details]
File: limits
Comment 8 Martin Gregorie 2015-07-27 18:41:34 EDT
Created attachment 1056777 [details]
File: maps
Comment 9 Martin Gregorie 2015-07-27 18:41:35 EDT
Created attachment 1056778 [details]
File: mountinfo
Comment 10 Martin Gregorie 2015-07-27 18:41:36 EDT
Created attachment 1056779 [details]
File: namespaces
Comment 11 Martin Gregorie 2015-07-27 18:41:38 EDT
Created attachment 1056780 [details]
File: open_fds
Comment 12 Martin Gregorie 2015-07-27 18:41:39 EDT
Created attachment 1056781 [details]
File: proc_pid_status
Comment 13 Martin Gregorie 2015-07-27 18:41:40 EDT
Created attachment 1056782 [details]
File: var_log_messages
Comment 14 Milan Crha 2015-07-28 01:09:58 EDT
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?
Comment 15 Martin Gregorie 2015-07-28 07:04:33 EDT
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?
Comment 16 Martin Gregorie 2015-07-28 18:58:21 EDT
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:

http://fairfaxmedia.newspaperdirect.com/epaper/viewer.aspx?noredirect=true

which is a reference to the newspaper article I was being asked to read.
Comment 17 Martin Gregorie 2015-07-28 19:02:46 EDT
Created attachment 1057175 [details]
Replying to the attached e-mail caused Evolution to crash.
Comment 18 Milan Crha 2015-07-29 02:38:08 EDT
(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:
https://bugzilla.gnome.org/show_bug.cgi?id=752997

(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:
https://bugzilla.gnome.org/show_bug.cgi?id=728739
Comment 19 Martin Gregorie 2015-07-29 07:18:16 EDT
> 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.
Comment 20 Fedora End Of Life 2016-07-19 13:13:05 EDT
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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.