Description: When trying to save the attached document as .uos format LibreOffice without error messages or anything. Steps to Reproduce: 1. Open attached document 2. File->save as 3. choose uos 4. insist on using uos Actual Results: crash without error message and an empty *.tmp file Expected Results: File saved Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: SpreadsheetDocument [Information guessed from browser] OS: Mac OS X (All) OS is 64bit: no
Created attachment 168336 [details] File for showing error
On Windows, with Version: 7.0.4.1 (x64) Build ID: e3cebc55238632eae061a3da668963d484a71147 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win Locale: en-US (zh_CN); UI: en-US Calc: threaded and Version: 7.1.0.0.beta1 (x64) Build ID: 828a45a14a0b954e0e539f5a9a10ca31c81d8f53 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: threaded I can not reproduce the crash. Both versions can save the sample document as .uos format. However, the saved .uos file can't be opened by LO. When trying to open LO gives a error dialog that says "General input/output error." I'm afraid the Unified Office format support in LO is very under-tested.
On pc Debian x86-64 with master sources updated today, I don't reproduce this and have exactly the same as Ming Hua. When trying to save the file in uos, I noticed this log 4 times: measure_conversion.xsl: Find no conversion for to 'cm'! After some debugging, the pb is in odf2uof_spreadsheet.xsl, the value "none" retrieved from internal LO from diagonal-bl-tr/diagonal-tl-br is not taken into account for border-width. Should it be "nil" "none" other? I don't find any specs/api for uos format in English.
Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
I tried resetting the user profile but that didn't change anything. Crash log is attached. One observation: On first start after resetting the user profile "Open File" didn't do anything, spinning ball for a while and nothing more (no dialog). After quitting and starting again Open File works again.
Created attachment 168387 [details] System crash log
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Julien Nabet from comment #3) > Should it be "nil" "none" other? I don't find any specs/api for uos format > in English. Yeah, I'm not even sure if a non-Chinese version of specification exists. The whole Chinese specification is available online, though under a horrible Flash-based reader: http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=C3C85F8E2E384424E49A0D3A35B47F85 From a cursory look it seems UOF uses "none". Though I didn't find the exact section about border-width, and was just finding "none" used in other places. I am happy to dig a bit more into the spec if Julien or other developers are interested in working on this.
Created attachment 168436 [details] console logs when opening uos I attached console logs when opening uos I'm afraid I can't help here. I just submitted a patch for review about "Find no conversion for to 'cm'!" message.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1edf1871079518f90e447c3de9df0c4ef5e1e3e4 Related tdf#139073: deal with "none" for border-width in odf2uof_spreadsheet It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Just my opinion but LO should focus on ODF import/export and only import for other formats. Indeed, there are too few devs to hope to bring a real support at all these formats. => uncc myself.
Julien Nabet: Is the crashing issue fixed by your commit?
(In reply to Kevin Suo from comment #12) > Julien Nabet: Is the crashing issue fixed by your commit? I don't believe so, since Julien couldn't even reproduce the crash. His commit was only about the warnings measure_conversion.xsl: Find no conversion for to 'cm'! ...he saw during export. The crash could be macOS specific.
I confirm a crach in macOS: Version: 7.2.0.0.alpha0+ Build ID: 4e63ec27b69fa01ff610c894c9fbf05c377a6179 CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded
*** Bug 141872 has been marked as a duplicate of this bug. ***
This is some kind of heap-corruption bug deep inside libxml/libxslt, which is unfortunately very hard to track down. It doesn't happen for me, with a debug build, only with a release build. It doesn't happen when I build with ASAN, so can't use that to find the source of the corruption. It happens with both system libxml and internal libxml. Enabling malloc heap checking doesn't seem to find it. At this point, out of ideas.
pretty sure it was solved along with bug#141421, at least the last comment from Noel makes me think it is the same. Could not reproduce with current 7.3 that has the fix, so pretty sure it is fixed. *** This bug has been marked as a duplicate of bug 141421 ***