Bug 677382 - [abrt] SdrMarkView::CheckSingleSdrObjectHit
Summary: [abrt] SdrMarkView::CheckSingleSdrObjectHit
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: 14
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:36b137d2492aecd90ddff29b383...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-14 15:01 UTC by Frank
Modified: 2011-03-08 20:49 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-08 20:49:35 UTC
Type: ---

Attachments (Terms of Use)
File: backtrace (44.88 KB, text/plain)
2011-02-14 15:01 UTC, Frank 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

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.
Note You need to log in before you can comment on or make changes to this bug.