The messages are fine and unrelated.

We have another user reporting the same thing. But I can not confirm myself unfortunately, so for now there is nothing  I can do.

Can you attach the file that doesn't work?

Created attachment 70394 [details]
file used for testing

As suspected it works nicely for me - can you tell me the version of gcc this was built with?

i did not compile it myself, but currently gcc 4.7.0 is packaged for arch linux so i think this is the version that was used.

I can confirm this with docx files and pptx as well.
Like Jozej I also use Arch with GCC 4.7.0 (although 64bit)...

he neglected to mention the other popup that reads something like this... (yes, there are two)

Could not open /home/user/document.doc
Reason: Not a valid Calligra file: /tmp/kde-user/wordsyJ1649.tmp

the following is also printed to a console if ran from there...

words(1649)/koffice (lib kopageapp) KoOdfLoadingContext::KoOdfLoadingContext: could not parse manifest document 

I'd assume that one's just a harmless debug message though, can't hurt to be sure.
The other debug messages seem to imply the document was correctly identified and read, before the popups show up and force the application to close, which makes this most curious.
(I built from git about an hour back)

Created attachment 70485 [details]
an invalid manifest

So I opened a docx file in calligrawords and when it threw the error, I copied the generated document to my home directory and extracted it...
Lo behold, the manifest is invalid (and it's attached).

There were quite a few manifest:file-entry lines and to my surprise, none of them were terminated
seriously, you have "<manifest:file-entry ..." followed up by "</manifest:file-entry>", none of them had a terminating '>' character!

indeed the generated manifest file is corrupted:

$ xmllint validate manifest.xml
warning: failed to load external entity "validate"
manifest.xml:4: parser error : error parsing attribute name
 </manifest:file-entry>
 ^
manifest.xml:4: parser error : attributes construct error
 </manifest:file-entry>
 ^
manifest.xml:4: parser error : Couldn't find end of Start Tag file-entry line 3
 </manifest:file-entry>
 ^
manifest.xml:4: parser error : Opening and ending tag mismatch: manifest line 2 and file-entry
 </manifest:file-entry>
                       ^
manifest.xml:5: parser error : Extra content at the end of the document
 <manifest:file-entry manifest:media-type="text/xml" manifest:full-path="styles.
 ^

$cat manifest.xml
<?xml version="1.0" encoding="UTF-8"?>
<manifest:manifest xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0" manifest:version="1.2">
 <manifest:file-entry manifest:media-type="application/vnd.oasis.opendocument.text" manifest:full-path="/"
 </manifest:file-entry>
 <manifest:file-entry manifest:media-type="text/xml" manifest:full-path="styles.xml"
 </manifest:file-entry>
 <manifest:file-entry manifest:media-type="text/xml" manifest:full-path="content.xml"
 </manifest:file-entry>
 <manifest:file-entry manifest:media-type="text/xml" manifest:full-path="settings.xml"
 </manifest:file-entry>
 <manifest:file-entry manifest:media-type="image/jpeg" manifest:full-path="Pictures/a0f8c4ad57a27fc0d6e1cb34b65c0ca1.jpg"
</manifest:file-entry>
 <manifest:file-entry manifest:media-type="text/xml" manifest:full-path="meta.xml"
 </manifest:file-entry>
</manifest:manifest>

The proposed fix:
https://git.reviewboard.kde.org/r/104677/
looks a lot like a workaround for a blatant compiler bug to me. Or is it normal that the implicit copy constructor does not work on bitfields? I think this should be reported (with a minimal testcase) to the GCC (g++) developers.

I tried a sample testcase and it worked fine with gcc 4.7

#include <iostream>

int main()
{

struct sampleStruct{
        sampleStruct() : myBitField(false) {}
        bool myBitField : 1;
} origStruct;

origStruct.myBitField = true;

if (origStruct.myBitField)
        std::cout<<"true";
else
        std::cout<<"false";

sampleStruct myCopy = origStruct;

if (myCopy.myBitField)
        std::cout<<"true";
else
        std::cout<<"false";
return 0;
}

Another thing I also tried is moving the KoXMLWriter to a new qt project and tried that out. Here too I was unable to reproduce the issue. The issue presents itself only when KoXMLWriter is used inside Calligra. I'm not sure if it is due to any compiler flags that are used while building

Git commit 9f3b7f62947ccda2335cdc8973d79c4cc7d62620 by Gopalakrishna Bhat A.
Committed on 20/04/2012 at 16:44.
Pushed by gopalakrishnabhat into branch 'master'.

With gcc 4.7 installed we where not able to save a odt file because the xml file that was generated was
missing the '>' for a tag. Example
 <manifest:file-entry manifest:media-type="" manifest:full-path="Thumbnails/thumbnail.png"
 </manifest:file-entry>

The missing close tag was because while doing a stack.pop the hasChildren (a bitfield) of Tag was not
populated correctly. This patch fixes this problem(workaround for a gcc bug? not sure)
REVIEW: 104677

M  +8    -0    libs/odf/KoXmlWriter.h

http://commits.kde.org/calligra/9f3b7f62947ccda2335cdc8973d79c4cc7d62620

Git commit 11a852fda159100b30546a91e710fbbf1ca23e1c by Gopalakrishna Bhat A.
Committed on 20/04/2012 at 16:44.
Pushed by gopalakrishnabhat into branch 'calligra/2.4'.

With gcc 4.7 installed we where not able to save a odt file because the xml file that was generated was
missing the '>' for a tag. Example
 <manifest:file-entry manifest:media-type="" manifest:full-path="Thumbnails/thumbnail.png"
 </manifest:file-entry>

The missing close tag was because while doing a stack.pop the hasChildren (a bitfield) of Tag was not
populated correctly. This patch fixes this problem(workaround for a gcc bug? not sure)
REVIEW: 104677
(cherry picked from commit 9f3b7f62947ccda2335cdc8973d79c4cc7d62620)

M  +8    -0    libs/odf/KoXmlWriter.h

http://commits.kde.org/calligra/11a852fda159100b30546a91e710fbbf1ca23e1c

*** Bug 298201 has been marked as a duplicate of this bug. ***

Git commit 6e4d171dfa5bad07e06277ef8e36d8a6a00005db by C. Boemann, on behalf of Gopalakrishna Bhat A.
Committed on 20/04/2012 at 16:44.
Pushed by boemann into branch 'tuneKoUnitAPI'.

With gcc 4.7 installed we where not able to save a odt file because the xml file that was generated was
missing the '>' for a tag. Example
 <manifest:file-entry manifest:media-type="" manifest:full-path="Thumbnails/thumbnail.png"
 </manifest:file-entry>

The missing close tag was because while doing a stack.pop the hasChildren (a bitfield) of Tag was not
populated correctly. This patch fixes this problem(workaround for a gcc bug? not sure)
REVIEW: 104677

M  +8    -0    libs/odf/KoXmlWriter.h

http://commits.kde.org/calligra/6e4d171dfa5bad07e06277ef8e36d8a6a00005db