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:
Created attachment 148388 [details] Content of the app.xml file from the original file
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
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.
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?!
Created attachment 148432 [details] Valgrind trace I tried to retrieve a Valgrind trace, don't know if it'll help.
it seems it hangs on linux and crashes on windows...
Not reproduced in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
In Version: 4.5.0.0.alpha0+ Build ID: 2851ce5afd0f37764cbbc2c2a9a63c7adc844311 Locale: ca_ES the file hangs at import time...
(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)
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.
FWIW, the string is 47Million characters long
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
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
(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!
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.
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
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!!
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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/85779dce8c2dd4fb8330d0c38b3599985d33b0ef tdf#122780: sw: Add UItest 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.