Bug 235548
Summary: | Open Office Calc crash on document close | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Christopher Beland <beland> |
Component: | openoffice.org | Assignee: | Caolan McNamara <caolanm> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-07-20 08:51:44 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: |
Description
Christopher Beland
2007-04-07 00:31:21 UTC
caolanm->beland: Can I get the output of readelf -S /usr/lib/openoffice.org2.0/program/libsvx680li.so | grep dynamic and readelf -S /usr/lib/openoffice.org2.0/program/libsc680li.so | grep dynamic please ? "readelf -S /usr/lib/openoffice.org2.0/program/libsvx680li.so | grep dynamic" produces: [20] .dynamic DYNAMIC 0338c8b0 bfb8b0 0001b0 08 WA 3 0 4 and "readelf -S /usr/lib/openoffice.org2.0/program/libsc680li.so | grep dynamic" produces: [20] .dynamic DYNAMIC 03d8c840 9d9840 0001a0 08 WA 3 0 4 Yeah, same as me. I can see where it crashes, but it can't be a simple NULL pointer given the code in question. So it's not possible to see from the trace why there's a clearly invalid pointer in there, the info as to where things have gone awry originally is not available, and some loading and closing of some calc docs with valgrind doesn't show any obvious problems. We'd need to be able to reproduce this at-will. I don't suppose there's any known way to get this to happen reproducibly ? Did this crash ever occur again since update 2.0.4-5.5.22 was released for FC-6 ? Hopefully this was fixed with the last FC-6 update To answer your earlier question which I somehow overlooked, this has only ever happened once. Thanks for your investigation. |