Bug 673730 - [abrt] midori-0.2.9-4.fc14: Process /usr/bin/midori was killed by signal 11 (SIGSEGV)
Summary: [abrt] midori-0.2.9-4.fc14: Process /usr/bin/midori was killed by signal 11 (...
Keywords:
Status: CLOSED DUPLICATE of bug 648319
Alias: None
Product: Fedora
Classification: Fedora
Component: midori
Version: 14
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Gordon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:7a58dfeb28010269b230243b9f6...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-30 08:12 UTC by Persona non grata
Modified: 2011-01-31 17:18 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-01-31 17:18:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (35.76 KB, text/plain)
2011-01-30 08:12 UTC, Persona non grata
no flags Details

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 ***


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