Created attachment 42676 [details]
http://www.weddingstar.com/templates/popups/flatpanel2a.wpd

Can't reproduce with m5 (build 9114) on WinXP - document opens without crash. 
Document appears to be empty.

My test was on Fedora Core 5, Linux 2.6.18.

Reassigned to SBA.

For me Writer just hungs (seemingly without CPU usage) with OO 9114 on Suse 
10.2 (KDE) when trying to import that file.

SBA: Added JW on C/C.
Opens empty on Windows XP in OOF680.m6.
Crashes on Linux (Suse 10.1) in Dev Build OOF680m7.
I sent a crash report naming this issue in the description.
I will attach the stack info from the recovery dialog.

Created attachment 42986 [details]
Stack from linux crash

SBA: Reassigned to fridrich_strba
Crashes on Solaris, too.
Set OS to "Unix, X11"

OK, the synopsis is following: the document is utterly broken. wplook.exe, the
WP recovery and document analysis tool is not recognizing the file-format at
all. Although, it is (according to the header), a document in WP 6.1+
file-format. The libwpd corruption-removal mechanism is trying to skip all
inconsistent functions and consier only those that do not seem corrupted. This
is achieved by a dry-run parsing of the function before the sharp parsing.
Nevertheless, this is not possible with single byte functions, because one just
reads the byte and cannot check whether it is well-formed. Unfortunately, in WP6
file-format there are some table related functions that have a single byte
version. In this document, due to the corruption, we were trying to insert a row
into a table that was not started. This was resulting on some operation done on
null pointer and that has not defined behaviour. Therefore, I kind of fixed this
in libwpg CVS by ignoring table related functions if table is not opened. It
makes this document open, but the result is really not worth it (font of 500+
points and the document results in ~1000 pages (2 chars per page) of more or
less garbage.
I will fix this issue in a CWS that is uploading a bugfix release of libwpd
0.8.9. Changing the target for 2.2.1

.

In my version of upcoming 2.3 it does not crash although it does not produce
anything usable either given the corruption of the document.
Jack, could you please verify whether this works in a vanilla build?

Hello fridrich_strba,
when I open the *wpd file in OOG m4, OOo crashes. If I use the program wpd2sxw
under Debian SID (AMD64 bit version) to convert the document to sxw without
error message. Afterwards I can open it in OOo. Maybe this helps :)
Thomas.

Fridrich, we must find the right target for this issue. As I don't know your
workload I leave it up to you to choose between 2.4, 3.0 and 3.x.

OK, libwpd 0.8.12 has a load of fixes. The only problem is that myself, I am
completely discouraged to do any CWS work ATM. So, if someone wants, this
version of library is working well in Go-oo and it is LGPL-ed. The thing would
be to upload it, make some QA guy to run the incantations on it and integrate.

The tarball is at http://libwpd.sf.net

So you mean exchanging our version 0.8.8 with 0.8.12 will help?
What about the patches against 0.8.8 we currently have in cvs? Will the file
become obsolete or do we need to adjust it?
In case we would need to adjust the patch: would you be so kind to help us doing
that? 
I can organize everything else (the CWS handling) by myself.

The patch will become useless and libwpd will even build with gcc 4.3 if the
tarball is 0.8.12

Sorry, I don't know what the patch does. But if you say me that we don't need
the patch if we upgrade to 0.8.12 I'll take that for granted.

OK, libwpd 0.8.8 and lower had an exploitable buffer overflow. I had a CWS where
I could put it without shouting too loud, because if I release libwpd before
OOo, iDefense would go public. So I did it in the patches. Is it enough background?
BTW: each release of libwpd is tested with more then 46000 documents for
regressions, I don't see any thorough Hamburg QA beat the results.

Thanks, Fridrich. I didn't ask because I was in any doubt about the quality of
your release. I just wasn't sure what might be in the patch. Thanks for
clarifying that.

Mathias, I would still wait for about a week or two with this one. With my QA
guy, we inflicted to each and every of the 46'000 documents a random corruption
using this tool: http://www.digitaldwarf.be/products/mangle.c
We discovered still that 5 of the corrupted documents were able to crash libwpd.
We fixed those crashes and we are instead terminating with an error. Although
the fix is already in, I am waiting for some thorough stress tests by my QA guy
before I release 0.8.13 so that we are completely sure that 0.8.13 will be the
most stable libwpd ever.

Thanks for letting me know. And of course thanks for the great filter work also. 

Any news on this one?

any news on this ?

As I said before, you are all free to take the freshest libwpd tarball and have
an up-to-date importer. But, as I also said before, I don't have any motivation
to do any upstream CWS/QA work on it. The freshest libwpd works well in
ooo-build and that is what I care about.

.

Whatever happened in the meantime, I couldn't reproduce the crash with OOo320m15.
Back to submitter for verification.

This was solved by removing libwpd altogether.