Apache OpenOffice (AOO) Bugzilla – Issue 55090
Ooo freezes when viewing page 37 of attached MSO document
Last modified: 2006-02-27 15:50:22 UTC
When I open the attached MS Word document and try to see page 37, Ooo freezes.
Created attachment 29905 [details] File that causes Ooo to freeze
just for the records: I don't get a problem viewing page 37/48 using m130 on Ubuntu-Linux...
I get the problem with Ooo 1.9.129 on Ubuntu (breezy) (and on every previous Ooo beta build) I can see any page but page 37, where Ooo freezes.
WFM with 2.0 (1.9.m125) German version WIN XP: [680m125(Build8947)] Only special LINUX problem?
cannot repro with m129 on suse 9.3
mci -> rainerbielefeld: no, this seems not to be a special Linux problem since this works here on my system... maxweber can't reproduce this, too...
Ok, no one seems to reproduce my problem :-( Maybe it's due to an environment problem (missing font, ...?) Is there a way I can help to track down the cause of this a give a more meaningful bug reprot ? (a debug mode or something ?)
MRU->US: I was not able reproduce the problem on Win and Solaris. MCI could not reproduce it on his Linux. Maybe this is something special due to font replacement on the user's Ubuntu Linuix. COuld please try to find out?
can not reproduce either. > Is there a way I can help to track down the cause you can try to attach to OO.o with gdb before it loops. determine OO.o's process ID: pgrep -fl soffice.bin attach to OO.o with gdb gdb - <pid> enter "continue" in gdb proceed as described in order to let OO.o loop interrup gdb with Ctrl+c (doesn't work with all shells, try xterm) type "bt" for a backtrace in gdb attach (!) the backtrace to this isue. That's it. Thanks a lot.
Created attachment 30335 [details] Stacktrace of the problem using gdb
Added attachment of gdb output. Hope this helps. The problem still occurs here with Ubuntu breezy + Ooo 1.9.129 Franck
Cool, thanks for the stack. But are you really sure that's a loop? I mean does top constantly report 97% CPU or more for soffice.bin? I doubt so. Pls. try to let OO.o format the document even if it takes 2 hours or more and report back whether it displays the page in question. I assume this is a configuration or bandwidth issue with your Xserver.
Hi, well, in fact I never said it loops, I said Ooo freezes... I mean that Ooo doesn't react any more, its window is not redrawn anymore, ... But the whole system is fine. So I am currently letting Ooo display the document on page 37, and gnome system monitor says soffice.bin is sleeping. So it might well be a problem with my xserver. But consider I am working in a local environment. So X is running localy on my laptop computer, and I am the only one connected to it. I am on Ubuntu, using xorg 6.8.2 and nvidia-glx binary driver (packaged by Ubuntu in restricted repository). I will let you know the result of letting Ooo try to render in unlimited time... Is there any info you need about my X configuration that might help ? Franck
NB : switching from nvidia driver to nv driver doesn't do any good... Don't know if that matters.
Frank, thanks for the input. So we can exclude a loop now. I have a question remaining. Did you interrupt OO.o with "Ctrl+c" when running inside gdb and reproducing the issue ? Or did the SIGABRT happen naturally?
Hi, this is how things happen here : 1) launch Ooo and open the doc. 2) in xterm, launch gdb - pid 3) hit enter, and gdb outputs a lot of stuff : [...] Loaded symbols for /usr/lib/openoffice2/program/libspell680li.so Reading symbols from /usr/lib/libmyspell.so.3... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libmyspell.so.3 0xffffe410 in ?? () 4) enter continue (gdb) continue Continuing. 5) in Ooo, go to page 37. Ooo freezes. 6) in xterm, I get this output : Program received signal SIGABRT, Aborted. [Switching to Thread -1232853312 (LWP 5783)] 0xffffe410 in ?? () (gdb) 7) in gdb, I type bt and copy the stacktrace. So the output at step 6 is not caused by me hitting Ctrl+C or anything else. It happens when I go to page 37.
Thanks for making this clear. @pl: is the attached stacktrace familar to you? (Note: generic vcl plugin)
pl->us: actually that's the gtk plugin, but that is not relevant. The abort() in free() clearly shows heap corruption. We have to reproduce and valgrind it to see what causes that. Since this seems to be reproducable on one machine only, it might indeed be a special font that triggers a bug in e.g. the psprint layer. Or it may be something completely different :-( .
pl->us: sorry, works without problems on my machine, too. Can you find me somewhere that reproduces this issue ?
us->mci: I suppose you tested this on Ubuntu too, did you? And you weren't able to reproduce this one, right? Thanks and regards, Ulf
mci -> us: Hi US, I tried this on Ubuntu-Linux 5.04 using m130 ( fom ftp.linux.cz) and didn't get the described problem...
In case this is of any help... here on my system, where the problem occurs, if I run oowriter2 from a shell, when freezing (trying to view page 37), I get this output : oowriter2 *** glibc detected *** double free or corruption (fasttop): 0x08338338 *** I don't know what it means or if it is of any help... Franck
alci, the error message underlines what PL explained (heap corruption). Unfortunately this error seems to be reproducible only at your side. Would you try a new build e.g. OO.o 2.0 (preferable the official build from the OO.o website) and report back whether the issue remains pls. thx.
Hi, I have come on another document that shows the same behaviour on my system. This time, it is a .sxw document. And opening both docs on another machine, I can see that in both documents, the problem comes from an image. Removing the image (on the other computer, where it works) and saving the doc resolves the issue on my system. Opening the .sxw faulty document in FileRoller shows me that the image has a .wmf extension and is a 'Microsoft WMV file'. So my problem comes when I try to view a page that contains a Microsoft WMV ebedded image. Does this give an indication of what 'component' on my system might make Ooo 'freeze' ?
Is it still reproducible with the official 2.0 build? Pls. understand that we can't support Ubuntu builds; if something does not work as it should in their build environment we'll never get that reproduced nor fixed here. Thanks for your comprehension.
This link offers a work-around: http://bugzilla.ubuntu.com/show_bug.cgi?id=18201 The advice is to export MALLOC_CHECK_=0 before running OpenOffice. A google search yields references to other people using this method for other software that gives the same error message.
Hi, yes, 'export MALLOC_CHECK_=0' before starting OOo does the trick. OOo doesn't lock anymore with this variable set... Weird, isn't it ? Stuff found on google related to this kind of workaround relate to any kind of software (netscape, kde, squid, ...). Does this mean there is a bug somewhere in OOo, occuring in certain circumstancies (not precisely known to me) when using malloc ?
That is exactly the case, there is some bug in OOo screwing up the heap (which is usually accessed basically by malloc/free). The problem is finding the circumstances in which this happens so we can fix that bug.
Possibly a duplicate of issue 53922? Both issues deal with freezes due to MSO documents for those running Ubuntu & using Ubuntu (?) OOo builds.
After further research, this is indeed a duplicate of 53922. However, I think there is more useful information in this issue, so I'm marking the duplicate the other way around.
*** Issue 53922 has been marked as a duplicate of this issue. ***
Can not reproduce with official OO.o builds. Seems to be Ubuntu/Debian specific. Retargetting due to limited resources.
Seems we have an ubuntu box (ask FPE) inhouse where this is reproducible now. us->pl: may I reassign and would you pls. contact FPE. Thx. in advance.
The stack trace makes this a duplicate of issue 58249 Sorry for not noticing earlier, but i didn't know about that problem in back in october *** This issue has been marked as a duplicate of 58249 ***
closing duplicate