Bug 677382

Summary: [abrt] SdrMarkView::CheckSingleSdrObjectHit
Product: [Fedora] Fedora Reporter: Frank <josefk838485>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: caolanm, dtardon
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:36b137d2492aecd90ddff29b3830c9049348d252
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-08 20:49:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace none

Description Frank 2011-02-14 15:01:29 UTC 
abrt version: 1.1.14
architecture: x86_64
Attached file: backtrace
cmdline: /usr/lib64/openoffice.org3/program/simpress.bin -impress file:///home/fkauff/Documents/MeetingsTalksPosters2007/Biosystematics2011/Presentation.odp
component: openoffice.org
executable: /usr/lib64/openoffice.org3/program/simpress.bin
kernel: 2.6.35.11-83.fc14.x86_64
package: openoffice.org-impress-1:3.3.0-20.2.fc14
rating: 4
reason: Process /usr/lib64/openoffice.org3/program/simpress.bin was killed by signal 11 (SIGSEGV)
release: Fedora release 14 (Laughlin)
time: 1297694849
uid: 500

How to reproduce
-----
1. just crashed out of the blue
2.
3.
Comment 1 Frank 2011-02-14 15:01:32 UTC 
Created attachment 478645 [details]
File: backtrace
Comment 2 David Tardon 2011-02-14 18:34:13 UTC 
You moved the mouse cursor over a drawing in the presentation. Does that ring a bell?
Comment 3 Frank 2011-02-14 19:49:08 UTC 
Possible. I can't think of anything special that I just did the moment it crashed. But if I remember correctly, clicking "undo" was one of the last actions.
Comment 4 Caolan McNamara 2011-03-08 20:49:35 UTC 
Can't see anything in the stack that easily explains this :-(

Did once see something in writer like this where the "fake" header objects were casted to something they weren't, causing a basically random method to be called, but that doesn't seem to be the case here.