Bug 242692
| Summary: | [fix available] impress crashes on StretchAndConvert method and cause X server freeze | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Jan Navratil <jnavrati> | ||||
| Component: | openoffice.org | Assignee: | Jan Navratil <jnavrati> | ||||
| Status: | CLOSED ERRATA | QA Contact: | desktop-bugs <desktop-bugs> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 5.0 | CC: | caolanm, dash, mmahut | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | RHBA-2008-0463 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-05-21 17:24:27 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
Jan Navratil
2007-06-05 13:54:28 UTC
So, from the traces it looks like a huge-ass memory allocation oh dear, the actual file itself contains the offending values, check out the 1.5 kilometer wide and 9.3 kilometer high object <draw:frame draw:style-name="gr98" draw:layer="layout" svg:width="1548550.143cm" svg:height="929628.159cm" svg:x="-27.769cm" svg:y="-10.377cm"> <draw:object-ole draw:class-id="00000000-0000-0000-0000-000000000000" xlink:href="./Object 3" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> <draw:image xlink:href="./ObjectReplacements/Object 3" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> </draw:frame> Created attachment 157085 [details]
patch to avoid crash
So attached is a patch which will avoid crashing, but the *real* question is
why were such ludicrous values written out on the initial save as.
So, I checked this workaround into F-7 and devel, and we can do it for a future RHEL-5. For Reference: How I debugged this. Just ran in gdb, it crashed in StretchAndConvert, saw it was a huge width causing it, backed up the stackframe and saw it was a huge aRect member in a SdrOleObj. But there was no direct assignment in the bt to that aRect, so added a static int i fprintf(stderr, "%d %x\n", i++, &(aRect.nBottom)); to SdrOleObj::Init and ran in gdb again, this time at the crash I did print &aRect.nBottom and checked the address against the output of the above and saw it was the 9th object, so run in gdb again and put a break point on that fprintf and on the 9th object did watch *(0xFOO) > 1000000 where 0xFoo was the output of print &(aRect.nBottom) for that 9th aRect and then cont gdb stopped OOo when the aRect was assigned the huge value, at that point I could see that the value was assigned from the original xml file through some code in xmloff to handle svg:width , so I unzipped the .odp and searched for svg:width and say the problem was in the original .odp. So: a) we still need to get an example document which we can show to upstream, I propose than Jan apply the patch to a local copy of OOo so it won't crash for him, and then use tools->options->openoffice.org->load/save and uncheck the size optimization (so that the xml is more readable) and then start cutting the document into halves, deleting either the 1st half of the set of slides, or the 2nd set and saving to temp .odps and unzipping them and checking for sillyy svg:widths like above. At some stage we should be able to get it down to a single slide and then scrub manually the content of the slide so that it has nothing we can't show to others in it. That'll be our sample document for reproducing this problem for upstream. b) ideally we could find out *why* we have such a large size for the object, if we have a then we will know which object is the problem and perhaps that'll identify why it might have occurred. openoffice.org-2.2.1-18.1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. in 2.3.0 by virtue of rebase An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0463.html |