Bug 139073 - Spreadsheet crashes when trying to save as .uos format (macOS only)
Summary: Spreadsheet crashes when trying to save as .uos format (macOS only)
Status: RESOLVED DUPLICATE of bug 141421
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: All macOS (All)
: high major
Assignee: Not Assigned
: 141872 (view as bug list)
Depends on:
Blocks: UOF
  Show dependency treegraph
Reported: 2020-12-19 16:21 UTC by Jørgen
Modified: 2022-10-17 10:42 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

File for showing error (18.10 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-12-19 16:23 UTC, Jørgen
System crash log (135.98 KB, text/plain)
2020-12-21 18:01 UTC, Jørgen
console logs when opening uos (1.73 KB, text/plain)
2020-12-22 21:32 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description Jørgen 2020-12-19 16:21:53 UTC
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
Comment 1 Jørgen 2020-12-19 16:23:02 UTC
Created attachment 168336 [details]
File for showing error
Comment 2 Ming Hua 2020-12-19 17:19:42 UTC
On Windows, with

Version: (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


Version: (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.
Comment 3 Julien Nabet 2020-12-19 22:29:42 UTC
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.
Comment 4 Xisco Faulí 2020-12-21 14:13:34 UTC
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
Comment 5 Jørgen 2020-12-21 18:00:43 UTC
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.
Comment 6 Jørgen 2020-12-21 18:01:27 UTC
Created attachment 168387 [details]
System crash log
Comment 7 QA Administrators 2020-12-22 03:44:02 UTC Comment hidden (obsolete)
Comment 8 Ming Hua 2020-12-22 16:45:37 UTC
(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:

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.
Comment 9 Julien Nabet 2020-12-22 21:32:49 UTC
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.
Comment 10 Commit Notification 2020-12-23 08:01:04 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":


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:

Affected users are encouraged to test the fix and report feedback.
Comment 11 Julien Nabet 2020-12-23 08:07:32 UTC
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.
Comment 12 Kevin Suo 2020-12-23 15:37:28 UTC
Julien Nabet: Is the crashing issue fixed by your commit?
Comment 13 Ming Hua 2020-12-23 16:39:10 UTC
(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.
Comment 14 Roman Kuznetsov 2020-12-26 22:54:55 UTC
I confirm a crach in macOS:

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
Comment 15 Michael Warner 2021-05-07 13:49:10 UTC
*** Bug 141872 has been marked as a duplicate of this bug. ***
Comment 16 Noel Grandin 2021-06-13 10:59:17 UTC
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.
Comment 17 Christian Lohmaier 2022-10-17 10:42:36 UTC
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 ***