Bug 673730

Summary: [abrt] midori-0.2.9-4.fc14: Process /usr/bin/midori was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Persona non grata <nobody+296696>
Component: midoriAssignee: Peter Gordon <peter>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: kevin, maxamillion, nobody+296696, peter
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:7a58dfeb28010269b230243b9f609a50f90c69d9
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-31 17:18:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace none

Description Persona non grata 2011-01-30 08:12:55 UTC 
abrt version: 1.1.14
architecture: x86_64
Attached file: backtrace
cmdline: midori
component: midori
crash_function: WTF::OSAllocator::reserveAndCommit
executable: /usr/bin/midori
kernel: 2.6.35.10-74.fc14.x86_64
package: midori-0.2.9-4.fc14
rating: 4
reason: Process /usr/bin/midori was killed by signal 11 (SIGSEGV)
release: Fedora release 14 (Laughlin)
time: 1296347666
uid: 500

comment
-----
Midori was never installed on this machine, so no forgotten config files could do this. Also, when I attempt to start it again, some dialog window appears, telling me that Midori did not exit properly last time. When starting from terminal, it prints (sorry for possible mistranslation):
Unauthorized memory access (SIGSEGV) (core dumped)

How to reproduce
-----
1. Install Midori from oficial repos
2. Attempt to start it, either from terminal, xfrun4 or applications menu
3. Wait a while, crash appears
Comment 1 Persona non grata 2011-01-30 08:12:58 UTC 
Created attachment 475993 [details]
File: backtrace
Comment 2 Kevin Fenzi 2011-01-30 20:51:28 UTC 
If you do:

echo 1 > /proc/sys/vm/overcommit_memory

does it start working again normally?
Comment 3 Persona non grata 2011-01-31 09:44:29 UTC 
Yes, browser starts normally now. But I can't test how it behaves after reboot..
Comment 4 Kevin Fenzi 2011-01-31 17:18:53 UTC 
This looks like another case of 648319 (a webkitgtk bug). 

The above works around it, and there's going to be a fix in the next upstream release.

*** This bug has been marked as a duplicate of bug 648319 ***