Bug 245738 - Crash when loading Word document (pow?)
Crash when loading Word document (pow?)
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
7
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-26 08:42 EDT by Matěj Cepl
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-20 04:50:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
mapped backtrace (4.47 KB, text/plain)
2007-06-26 10:30 EDT, Caolan McNamara
no flags Details
mapped backtrace, including glibc (5.08 KB, text/plain)
2007-06-27 07:56 EDT, Caolan McNamara
no flags Details
x86_64 pngcrush binary (229.90 KB, application/octet-stream)
2007-07-10 15:30 EDT, Caolan McNamara
no flags Details

  None (edit)
Description Matěj Cepl 2007-06-26 08:42:02 EDT
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?
Comment 1 Caolan McNamara 2007-06-26 10:30:16 EDT
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.
Comment 2 Caolan McNamara 2007-06-26 10:38:11 EDT
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);


Comment 3 Caolan McNamara 2007-06-26 14:11:48 EDT
Is this reproducible ?
Comment 4 Matěj Cepl 2007-06-26 16:00:45 EDT
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).
Comment 5 Caolan McNamara 2007-06-27 02:49:24 EDT
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 ?
Comment 6 Caolan McNamara 2007-06-27 07:56:05 EDT
Created attachment 157996 [details]
mapped backtrace, including glibc
Comment 7 Matěj Cepl 2007-06-27 09:00:12 EDT
If you mean extensions, only your ooblogger (which doesn't work anyway).
Comment 8 Caolan McNamara 2007-07-10 10:19:20 EDT
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.
Comment 9 Jakub Jelinek 2007-07-10 13:18:55 EDT
Do you know the exact value of fInvGamma in this case, even if you can't
reproduce the crash?
Comment 10 Caolan McNamara 2007-07-10 14:24:10 EDT
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 );
Comment 11 Jakub Jelinek 2007-07-10 14:36:23 EDT
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.
Comment 12 Caolan McNamara 2007-07-10 15:30:02 EDT
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.
Comment 13 Caolan McNamara 2007-07-10 15:38:54 EDT
number = nGammaValue I mean of course, not fGamma, i.e. nGammaValue should in
theory be one of those 7 values from 22727 to 55000
Comment 14 Jakub Jelinek 2007-07-11 05:40:24 EDT
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.
Comment 15 Caolan McNamara 2007-07-11 06:44:03 EDT
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.
Comment 16 Caolan McNamara 2007-07-20 04:50:21 EDT
Can't reproduce, or identify a plausible reason for a bizarre gamma value

Note You need to log in before you can comment on or make changes to this bug.