Issue 124495 - Crash when open document
Summary: Crash when open document
Status: CLOSED IRREPRODUCIBLE
Alias: None
Product: Writer
Classification: Application
Component: open-import (show other issues)
Version: 4.0.1
Hardware: Mac OS X 10.9
: P3 Normal (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: needmoreinfo
Depends on:
Blocks:
 
Reported: 2014-03-24 09:41 UTC by p.jungwirt
Modified: 2017-08-16 22:30 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
fault message (34.45 KB, application/vnd.oasis.opendocument.text)
2014-03-24 09:41 UTC, p.jungwirt 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description p.jungwirt 2014-03-24 09:41:23 UTC 
Created attachment 82962 [details]
fault message

SYMPTOMS:

Open an odt document

Go to "OpenOffice -" Settings "

Click" Open Office Writer "

" OpenOffice "is terminated

bug report is created

recovery option is displayed.
Comment 1 Oliver-Rainer Wittmann 2014-03-25 07:13:07 UTC 
I was not able to reproduce the described crash on Mac OS X 10.9.2 nor with AOO 4.0.1 neither in AOO 4.1.0 Beta.

@p.jungwirt:
- Does the crash also occur, if you create a new text document instead of loading one?
- Does the crash occur with every ODF text document (*.odt)?
- Does the crash also occur with text document in other file formats (e.g. *.txt, *.rtf, *.doc, *.docx)
Comment 2 Andre 2014-03-25 08:25:35 UTC 
The bugdoc shows an endless recursion in hitTestRunner (vcl/aqua/source/a11y/aqua11ywrapper.mm).  This implies that accessibility support has to be active in order to reproduce the bug.

@p.jungwirt: Did you have accessibility support active when the crash occured?
Comment 3 Andre 2014-03-25 08:55:04 UTC 
At the moment I can not debug on Mac.  After looking at the code and the stack trace maybe the following scenario could explain the crash:

hitTestRunner is called for some (yet unknown) control C0.  A call to getAccessibleAtPoint returns another control C1 for the given point.  hitTestRunner is called for C1, does not find any control via getAccessibleAtPoint, and iterates over all children of C1.  One of the children is C0.  hitTestRunner is called again for C0 and we are in a loop that ends with a stack overflow.

If this scenario is correct then the only thing I can say about C0 is that its accessible role is not AccessibleRole::LIST.
Comment 4 oooforum (fr) 2017-08-16 13:20:54 UTC 
No news from OP: closed