Created attachment 56065 [details] The file that causes abnormal program end Problem description: When I try to save my ODT file like a Word Document 97/2000(*.doc)the program crash.. It seems that is due to the table content. I attach the example file to reproduce the problem. Steps to reproduce: 1. ....Open odt document 2. ....Save as Word DOcument 97/2000 (*.doc). 3. ....Save-> Matein current format.. Current behavior: The writer close with next error: Nombre del evento de problema: BEX Nombre de la aplicación: soffice.bin Versión de la aplicación: 3.4.502.500 Marca de tiempo de la aplicación: 4f0383cd Nombre del módulo con errores: MSVCR90.dll Versión del módulo con errores: 9.0.30729.4926 Marca de tiempo del módulo con errores: 4a1743c1 Desplazamiento de excepción: 0006c955 Código de excepción: c0000417 Datos de excepción: 00000000 Versión del sistema operativo: 6.1.7600.2.0.0.768.3 Id. de configuración regional: 3082 Información adicional 1: 8faa Información adicional 2: 8faa19d559b934f5df39f28cf3d4ccde Información adicional 3: 1c76 Información adicional 4: 1c763ae58c04f6fdb46aed48c3c2f13a Lea nuestra declaración de privacidad en línea: http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0c0a Si la declaración de privacidad en línea no está disponible, lea la declaración de privacidad sin conexión: C:\Windows\system32\es-ES\erofflps.txt Expected behavior: Platform (if different from the browser): Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
NOT reproduced with LOdev 3.5.0rc1 e40af8c-10029e3-615e522-88673a2-727f724 Ubuntu 10.04.3 x86 Linux 2.6.32-37-generic Russian UI Feel free to reopen if this bug is still there for you with 3.5.
Try it with OS: Windows 7 Home Premium. (es_ES)
When I try to install LibO_3.5.0rc2_Win_x86_install_multi.msi the Avira Antivir detects TR/Kazy.7720 into soffice.bin. ;(
@Rainer What can you say?
It is related with bug 45227. This troyan is inside the original executable or installation. Is it a false alert? It forces me to disable the antivirus to work with the LibreOffice 3.5 ... very annoying. ;(
Created attachment 62505 [details] Bug 45165 - WinDbg session Confirmed with: LO 3.5.4.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Crash while saving as .doc. Attached full WinDbg session with mini dump file loaded generated by procdump soffice.bin -h.
On pc Debian x86-64 with 3.6 sources updated 2 days ago, I don't reproduce the crash. I'll give a try to LO Win 3.6.4
On Win7 with LO 3.6.4.3 (French localization), I don't reproduce the crash. qualigy/bfoman: do you still reproduce this with 3.6.4?
bfoman: I hadn't noticed you weren't on cc. Would you have some time to give it a new try?
(In reply to comment #9) > bfoman: I hadn't noticed you weren't on cc. Would you have some time to give > it a new try? Checked with: LO 4.0.0.3 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Could not reproduce the crash when save as .doc. Crashes when saved as .docx. Apart from above there are also problems with a conversion - misplaced table on a page, missing left/bottom borders in merged cells. Word 2010 doesn't display the file as LibreOffice.
Created attachment 74283 [details] Bug 45165 - save as docx crash screenshot Bug 45165 - save as docx crash screenshot
On pc Debian x86-64 with master sources updated today, I don't reproduce crash when exporting to .doc but noticed this logs repeated a lot of times: warn:legacy.osl:12553:1:sw/source/core/doc/fmtcol.cxx:641: <SwTxtFmtColl::GetAssignedOutlineStyleLevel()> - misuse of method However, crash when exporting in docx, will a new comment.
Created attachment 74472 [details] bt + console logs on master when exporting in docx I attached bt + console logs when exporting in docx. Noticed too some errors with http://odf-validator2.rhcloud.com/odf-validator2/ eg: Sin t?tulo 1.odt/styles.xml[2,10968]: Error: unexpected attribute "style:layout-grid-snap-to-characters" Sin t?tulo 1.odt/content.xml[2,3318]: Error: unexpected attribute "style:keep-together" Sin t?tulo 1.odt/content.xml[2,4125]: Error: unexpected attribute "style:keep-together" Sin t?tulo 1.odt/content.xml[2,6231]: Error: unexpected attribute "style:keep-together" Sin t?tulo 1.odt/content.xml[2,8321]: Error: unexpected attribute "style:keep-together"
bfoman: had forgotten to thank you for your feedback, mistake fixed :-) I removed manually style:layout-grid-snap-to-characters in style.xml but no changes. Anyway, I put in see also https://bugs.freedesktop.org/show_bug.cgi?id=44073 I also noticed that layout-grid-snap-to-characters was still there in LO code, see http://opengrok.libreoffice.org/xref/core/xmloff/source/core/xmltoken.cxx#2143 Michael: one for you?
Created attachment 89353 [details] console + bt with master sources With master sources updated yesterday, I still reproduce this. I attached a new bt.
The crash saving to .docx still occurs on current 4.4 master, and in fact also all the way back to 3.3.0 A quick poke around suggests some paragraph/table confusion - we are closing out a table, then trying to emit a paragraph that belongs inside it This only appears to occur for "complex" tables that pass through WW8TableInfo::processSwTableByLayout(...)
This is also not specific to Windows - setting platform to All
The key to this seems to be not the style:... attributes mentioned above, but the use of the table:is-sub-table attribute It's not obvious how it is possible to cause this apparently little-used attribute to be used in the first place (short of adding it manually to the XML), but the attached document does, and removing the attribute causes the export to work
Matthew - you assigned the bug to yourself - are you going to fix it?
I intend to yes - it's been around an embarrassingly long time for a crasher I've got some idea of the scope of the problem but it's not clear yet how simple the solution is going to be. I'm told the sub-tables feature is deprecated, and there hasn't been a UI to create them since the days of OOo 2.0 (but of course we should still maintain compatibility with old documents) What the docx filter is doing appears to be fairly "unique" in terms of how it's parsing the structure of the table in question, so the next stop is probably to analyse how other export filters handle this case, if at all.
This stopped crashing on export between 7bff8c4b69a21a0b78b87c975f8e3aa772d6c2bd and 3d54555a1e7d79f00a8ba309cf821f0e5f48be21 with the export crashtesting improvements Probably 4eff3e7c455e8db2c00b7ee5eb1d2296b45d2823