Bug 122780 - FILEOPEN DOCX Crash with too long Template tag in app.xml
Summary: FILEOPEN DOCX Crash with too long Template tag in app.xml
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha0+ Master
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.3.0 target:6.2.4
Keywords: bibisectRequest, regression
Depends on:
Blocks: File-Properties
  Show dependency treegraph
 
Reported: 2019-01-17 08:39 UTC by Gabor Kelemen
Modified: 2019-04-08 18:29 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
The problematic docx file (without actual content) (91.53 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-01-17 08:39 UTC, Gabor Kelemen
Details
Content of the app.xml file from the original file (69.68 KB, image/png)
2019-01-17 08:40 UTC, Gabor Kelemen
Details
Screenshot of the crash (22.38 KB, image/png)
2019-01-17 12:54 UTC, Gabor Kelemen
Details
Valgrind trace (26.20 KB, application/x-bzip)
2019-01-19 10:53 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gabor Kelemen 2019-01-17 08:39:12 UTC
Created attachment 148387 [details]
The problematic docx file (without actual content)

Attached user-made docx (last edited with 6.0.6) somehow has an overly long Template tag in docProps/app.xml which makes LO crash when opening File - Properties.

Version: 6.3.0.0.alpha0+
Build ID: cec7ae9f3c69ecc83462f28fc4987e37dc1b420e
CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; 
Locale: hu-HU (hu_HU); UI-Language: en-US
Calc:
Comment 1 Gabor Kelemen 2019-01-17 08:40:09 UTC
Created attachment 148388 [details]
Content of the app.xml file from the original file
Comment 2 Dieter Praas 2019-01-17 12:47:54 UTC
No crash, but LO becomes unresponsive for more than 10 seconds if you try to open the file-properties dialog and even more, if you select a tab within that dialog.

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 411f3a050ac2be598019d512f8ccfe041080c28f
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-01-14_03:17:11
Locale: en-US (de_DE); UI-Language: en-US
Calc: threaded

More terrible in

Version: 6.1.4.2 (x64)
Build-ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group threaded

Documetn becomes unresponsive, when I open it and it takes much more time to open the file-property dialog
Comment 3 Gabor Kelemen 2019-01-17 12:54:33 UTC
Created attachment 148399 [details]
Screenshot of the crash

I see this all the time with the bibisect-win32-6.3 version updated today.

Also the document opens terribly slowly in 6.1.x, but not in current 6.2, so I didn't mention that part.
Comment 4 Julien Nabet 2019-01-19 09:58:25 UTC
On pc Debian x86-64 with master sources updated yesterday, I had to force down the shutdown of Linux because it was unresponsive.
I don't know if it's due to Linux, LO or simple me but quite depressing to see such things in 2019. Why a simple alt Tab in order to make Ctrl-C on LO launched from terminal doesn't work?!
Comment 5 Julien Nabet 2019-01-19 10:53:47 UTC
Created attachment 148432 [details]
Valgrind trace

I tried to retrieve a Valgrind trace, don't know if it'll help.
Comment 6 Xisco Faulí 2019-01-21 18:09:53 UTC
it seems it hangs on linux and crashes on windows...
Comment 7 Xisco Faulí 2019-01-21 18:11:20 UTC
Not reproduced in

Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Comment 8 Xisco Faulí 2019-01-21 18:14:29 UTC
In

Version: 4.5.0.0.alpha0+
Build ID: 2851ce5afd0f37764cbbc2c2a9a63c7adc844311
Locale: ca_ES

the file hangs at import time...
Comment 9 Dieter Praas 2019-01-21 18:17:01 UTC
(In reply to Xisco Faulí from comment #6)
> it seems it hangs on linux and crashes on windows...

It hangs with windows 10 (see comment 2).
It crashes with windows 6.3 (see bug description)
Comment 10 Commit Notification 2019-01-31 08:54:13 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/07ec9edc26f675646f04721acb3f1f0334a34530%5E%21

Related: tdf#122780 skip GetTextWidth() when we don't need the result

It will be available in 6.3.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.
Comment 11 Caolán McNamara 2019-02-14 15:46:38 UTC
FWIW, the string is 47Million characters long
Comment 12 Xisco Faulí 2019-03-21 11:46:27 UTC
Still reproducible in

Version: 6.3.0.0.alpha0+
Build ID: 7c7a4675ad5d61add70dd073f680ea37012962ce
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 13 Caolán McNamara 2019-04-04 12:09:21 UTC
its clearly an unreasonable length, there isn't anything in the spec however to justify clipping it at some arbitrary level, so lets clip it in the dialog to something like the max path length of the OS
Comment 14 Gabor Kelemen 2019-04-04 12:19:39 UTC
(In reply to Caolán McNamara from comment #13)
> its clearly an unreasonable length, there isn't anything in the spec however
> to justify clipping it at some arbitrary level, so lets clip it in the
> dialog to something like the max path length of the OS

I can swear to you that this document was made by an actual user who uses both MSO 2007 and LO - and somehow these interacted in weird ways resulting in the bugdoc.

Thanks for your time!
Comment 15 Commit Notification 2019-04-04 13:30:27 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/9db7130e05b79fdcb9a60a3f1f4801e5401427de%5E%21

Resolves: tdf#122780 limit massive template names in ui to a sane length

It will be available in 6.3.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.
Comment 16 Caolán McNamara 2019-04-04 13:36:30 UTC
yeah, there's clearly a more "interesting" bug somewhere that causes the creation of such a long Template string. Ideally we could determine who is doing that, us or them and if us fix it. In the meantime I've tried to address the fallout without a frozen/crashed UI

Fixed in master, backport to 6-2 in gerrit
Comment 17 Xisco Faulí 2019-04-08 09:55:20 UTC
Verified in

Version: 6.3.0.0.alpha0+
Build ID: 31ac398cfa30694b18240d31df17a58d699b5bf6
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

@Caolán, thanks for fixing this issue!!
Comment 18 Commit Notification 2019-04-08 18:29:15 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/386b9a1bebb56367977ebc276d85f5f10d252be6%5E%21

Resolves: tdf#122780 limit massive template names in ui to a sane length

It will be available in 6.2.4.

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.