Bug 245738
| Summary: | Crash when loading Word document (pow?) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matěj Cepl <mcepl> | ||||||||
| Component: | openoffice.org | Assignee: | Caolan McNamara <caolanm> | ||||||||
| Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | low | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 7 | CC: | jakub, mcepl | ||||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2007-07-20 08:50:21 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: |
|
||||||||||
Created attachment 157901 [details] mapped backtrace Because the debuginfo is so insanely huge, see http://fedoraproject.org/wiki/OpenOffice.org for ooomapstack which maps this back to source lines. Though I've done this for this example. But apparently this crashed in "pow", which strikes me as totally insane beyond words. mpColorTable = new sal_uInt8[ 256 ];
for ( sal_Int32 i = 0; i < 256; i++ )
mpColorTable[ i ] = (sal_uInt8)(pow((double)i/255.0, fInvGamma) * 255.0 + 0.5);
Is this reproducible ? Just curious -- how bis is "insanely huge"? (no, I don't want to install it, just curious). To your question: no, I hope it is not reproducible -- when I opened the same document from the Evolution again (well, after two crashes of Evolution -- but instability of Evo in F7 is another story, I suppose) it opened without a problem and I have never encountered this bug before (crash in pow()??? -- that's really weird). 450 Megs. rats, I hate the irreproducible ones. Indeed a pow crash is a new one on me. The source is from loading the png file for use as the icon for the toplevel window. I guess I can try and run in valgrind a few times to see if there's anything suspicious going on. Is this default setting for OOo ? i.e. no customization of the openoffice.org theme ? Created attachment 157996 [details]
mapped backtrace, including glibc
If you mean extensions, only your ooblogger (which doesn't work anyway). I can't see any reason why this would fail, especially once and not everytime. I can't imagine that "pow" was busted on x86_64! :-), unless jakub knows different. So it must be some other problem that I can't recapture, going to have to give up on this one unless anyone has any other insight. Do you know the exact value of fInvGamma in this case, even if you can't reproduce the crash? no way to know without a reproducer with fInvGamma might have been. #define VIEWING_GAMMA 2.35 #define DISPLAY_GAMMA 1.0 sal_uInt32 nGammaValue = /*, where foo is read from the png file...*/ double fGamma = ( ( VIEWING_GAMMA / DISPLAY_GAMMA ) * ( (double)nGammaValue / 100000 ) ); double fInvGamma = ( fGamma <= 0.0 || fGamma > 10.0 ) ? 1.0 : ( 1.0 / fGamma ); Matej, do you have the document which caused this crash? Can you find out
that value from the embedded png file in it (or multiple if there is more than
one)?
j = v.i[LOW_HALF]&0x0007ffff;
j = j+j+j;
eps = u.x - uu*vv;
ov = vj.x[j];
lv1 = vj.x[j+1];
lv2 = vj.x[j+2];
is where it crashed. The vj array is actually shorter than 0x80000*3 entries,
so it doesn't surprise me, but the code is quite convoluted and this can be
reached only in very rare circumstances, therefore a testcase would be extremely
helpful for fixing this issue.
Created attachment 158884 [details]
x86_64 pngcrush binary
FWIW, with this attachment "pngcrush", then
pngcrush -v -n file.png | grep gamma
will output the gamma in number/10000 where number is the fGamma value used in
the above code.
FWIW the OOo icon theme and so on are of course .pngs, here're the gammas for
the default theme on F-7
i.e.
unzip /usr/lib64/openoffice.org/share/config/images.zip
unzip -o /usr/lib64/openoffice.org/share/config/images_tango.zip
find . -name "*.png" -exec /tmp/pngcrush {} -n -v {} \; | grep gamma|sort|uniq
gamma=(22727/100000)
gamma=(37096/100000)
gamma=(45454/100000)
gamma=(45455/100000)
gamma=(45470/100000)
gamma=(55000/100000)
The code in question is the SetIcon code, which I *think* should be loading a
png from the above collection.
number = nGammaValue I mean of course, not fGamma, i.e. nGammaValue should in theory be one of those 7 values from 22727 to 55000 Can't reproduce.
I ran
#include <math.h>
unsigned int arr[] = { 22727, 37096, 45454, 45455, 45470, 55000 };
volatile unsigned int v;
int
main (void)
{
#define VIEWING_GAMMA 2.35
#define DISPLAY_GAMMA 1.0
for (int j = 0; j < 1000000; j++)
{
double fGamma = ((VIEWING_GAMMA / DISPLAY_GAMMA) * ((double) j / 100000));
double fInvGamma = (fGamma <= 0.0 || fGamma > 10.0) ? 1.0 : (1.0 / fGamma);
for (int i = 0; i < 256; i++)
v = (unsigned int) pow((double) i / 255.0, fInvGamma) * 255.0 + 0.5;
}
return 0;
}
against a modified libm which would abort if j=j+j+j was bigger or equal than
2175 (size of vj.x array) - right before the exact instruction where you saw
the crash. It succeeded, so if the above is what OOo really does, then
the crash is not possible.
Starting OOo under GNOME with default installed theme does use a subset of the above pngcrush reported values for nGammaValue. I can't see where any strange value could have come from, except from some other corruption, so we're back to can't reproduce. Can't reproduce, or identify a plausible reason for a bizarre gamma value |
Description of problem: loading word document from Evolution I got this crash: (I) x.org loaded video driver of... (II) Loading /usr/lib64/xorg/modules/drivers//radeon_drv.so (II) Loading /usr/lib64/xorg/modules/drivers//ati_drv.so (II) Reloading /usr/lib64/xorg/modules/drivers//radeon_drv.so (III) Desktop is: GNOME (IV) libgcj version is: libgcj-4.1.2-12-x86_64 (V) kernel is: Linux 2.6.20-2925.11.fc7xen #1 SMP Mon Jun 11 16:18:59 EDT 2007 x86_64 x86_64 x86_64 (VI) OpenOffice.org core rpm version is: openoffice.org-core-2.2.0-14.11-x86_64 (VII) depth of root window: 24 planes (VIII) accessibility is: false (VIV) fedora release is: Fedora release 7 (Moonshine) ...start free space details ... Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vol0-log102 53902404 47322932 3797472 93% /home /dev/mapper/vol0-log101 27646996 21707224 4512728 83% / ...end free space details ... ...start sestatus details ... SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 21 Policy from config file: targeted ...end sestatus details ... ...start stackreport details ... 0x0000003070036808: 0x00000000001e9d08: /usr/lib64/openoffice.org/program/libuno_sal.so.3 + 0x36808 0x000000307003730b: 0x00000000001e9d08: /usr/lib64/openoffice.org/program/libuno_sal.so.3 + 0x3730b 0x00000033cc430620: 0x0000000000149b60: /lib64/libc.so.6 + 0x30620 0x00000033cc812998: 0x0000000000081de8: /lib64/libm.so.6 + 0x12998 0x00000033cc823c03: 0x0000000000081de8: /lib64/libm.so.6 + 0x23c03 (pow + 0x33) 0x0000003f4b1ffb51: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0x1ffb51 0x0000003f4b201e18: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0x201e18 0x0000003f4b201fbb: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0x201fbb (vcl::PNGReader::Read() + 0x1b) 0x0000003f4b133040: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0x133040 0x0000003f4b134e60: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0x134e60 0x0000003f4b10164f: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0x10164f (BitmapEx::BitmapEx(ResId const&) + 0xdf) 0x00002aaaaeaf211a: 0x0000000000050488: /usr/lib64/openoffice.org/program/libvclplug_gtk680lx.so + 0x3b11a 0x00002aaaaeaf17a9: 0x0000000000050488: /usr/lib64/openoffice.org/program/libvclplug_gtk680lx.so + 0x3a7a9 0x00002aaaaeaf26e9: 0x0000000000050488: /usr/lib64/openoffice.org/program/libvclplug_gtk680lx.so + 0x3b6e9 0x00002aaaaeaf4280: 0x0000000000050488: /usr/lib64/openoffice.org/program/libvclplug_gtk680lx.so + 0x3d280 0x00002aaaaead1a35: 0x0000000000050488: /usr/lib64/openoffice.org/program/libvclplug_gtk680lx.so + 0x1aa35 0x0000003f4b27db43: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0x27db43 0x0000003f4b20a9fa: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0x20a9fa 0x0000003f4b20ab78: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0x20ab78 0x0000003f4b28d223: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0x28d223 0x0000003f4b28d49e: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0x28d49e (WorkWindow::WorkWindow(Window*, long) + 0x4e) 0x0000003f4b0da60c: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0xda60c 0x0000003f4b0d9249: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0xd9249 (Application::PostUserEvent(unsigned long&, Link const&, void*) + 0x99) 0x0000003f4b0d92ba: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0xd92ba (Application::PostUserEvent(Link const&, void*) + 0x1a) 0x0000003f4ee28127: 0x0000000000054798: /usr/lib64/openoffice.org/program/libsoffice.so + 0x28127 (desktop::Desktop::Main() + 0xd27) 0x0000003f4b0dd2a4: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0xdd2a4 0x0000003f4b0dd305: 0x000000000039dd28: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0xdd305 (SVMain() + 0x25) 0x0000003f4ee2142b: 0x0000000000054798: /usr/lib64/openoffice.org/program/libsoffice.so + 0x2142b (main + 0x4b) 0x00000033cc41daa4: 0x0000000000149b60: /lib64/libc.so.6 + 0x1daa4 (__libc_start_main + 0xf4) 0x0000000000400619: 0x0000000000000870: /usr/lib64/openoffice.org/program/swriter.bin + 0x619 (main + 0x49) ...end stackreport details ... ...start sample ldd details ... libuno_sal.so.3 => /usr/lib64/openoffice.org/program/libuno_sal.so.3 (0x00002aaaaaccd000) libuno_salhelpergcc3.so.3 => /usr/lib64/openoffice.org/program/libuno_salhelpergcc3.so.3 (0x00002aaaab0c2000) libstore.so.3 => /usr/lib64/openoffice.org/program/libstore.so.3 (0x00002aaaab2c6000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaab4f8000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab6fc000) libstlport_gcc.so => /usr/lib64/openoffice.org/program/libstlport_gcc.so (0x00002aaaab916000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaabbe4000) libm.so.6 => /lib64/libm.so.6 (0x00002aaaabee4000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaac167000) libc.so.6 => /lib64/libc.so.6 (0x00002aaaac376000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaac6c6000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) ...end sample ldd details ... Version-Release number of selected component (if applicable): openoffice.org-writer-2.2.0-14.11 How reproducible: happened once Steps to Reproduce: 1.in Evolution click on Word attachment and select Open in Wordprocessor... 2.collect backtrace 3. Which -debuginfo packages I should install to make the stack useful?