| Summary: | Crash (failed assert) in DBGUTIL build when inserting a section from a WEBP | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Mike Kaganski <mikekaganski> |
| Component: | LibreOffice | Assignee: | Caolán McNamara <caolan.mcnamara> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caolan.mcnamara, erack, martin_hosken |
| Priority: | medium | ||
| Version: | 7.3.0.0 alpha1+ | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | target:7.4.0 | ||
| Crash report or crash signature: | Regression By: | ||
| Attachments: | A WEBP image ( source: https://upload.wikimedia.org/wikipedia/commons/a/a1/Johnrogershousemay2020.webp ) | ||
|
Description
Mike Kaganski
2021-11-25 16:00:29 UTC
Khmer?? Mike, could you please try if the same happens with ICU 69 (temporarily revert commit 263961306ede0656ebb7904034a2172615ce81d0), and if with ICU 70 not applying external/icu/icu4c-khmerbreakengine.patch.1 helps? Thanks. Fwiw, I could not reproduce in a fresh clean build of current master with bundled internal ICU 70.1 on Linux. It takes ~50 minutes to load and analyse the Unicode "script" runnings to finally display garbage in Writer, but no crash in ICU. Later when scrolling application seems to be stuck and spews out loads of warn:vcl:808605:808605:vcl/source/outdev/text.cxx:1309: Trying to setup invalid cached glyphs - falling back to relayout! interspersed with warn:vcl.fonts:808605:808605:vcl/unx/generic/fontmanager/fontconfig.cxx:935: In glyph fallback throwing away the language property of hi because the detected script for '0xb75' is Oriya and that language doesn't make sense. Autodetecting instead. and other script values. Finally Gdk-Message: 18:49:28.953: Error flushing display: Broken pipe and application quits with exit value 1. (In reply to Eike Rathke from comment #2) Thank you for looking into this. Sorry for me not responding timely! My Windows build also uses ICU 70.1 (or at least, that's what ICU's config.log reports in workdir/UnpackedTarball/icu/source). I suppose that the specific of this case puts it into a "fuzz" testing? Caolan: could you please take a look at it (if you have a Windows box for testing - it seems it is Windows-specific)? I see it under windows with ICU 69 so its not new with the upgrade AFAICS looks like the assert is from our external/icu/icu4c-khmerbreakengine.patch.1 extra patch which we're carrying since commit fbb00383d82da5ce375f1b034d3fb9ebdd9a8f0e Author: Martin Hosken <martin_hosken@sil.org> Date: Sat Dec 12 11:36:53 2015 +0700 Use .dict files since below the 500K limit Change-Id: Iec71ad4918cd333f0a44d372017ecee300e3aca9 Reviewed-on: https://gerrit.libreoffice.org/20748 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Martin Hosken <martin_hosken@sil.org> where the upstream attempt seems to be https://unicode-org.atlassian.net/browse/ICU-12504 which looks stalled. we're not in particularly great shape with this file with the patch disabled either though. lets just disable the assert for dbgutil, it does eventually layout for me with no ill effect. Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d4b6c35eeba661f721d0204d4a2c581913fc38b7 tdf#145892 disable failing assert in additional icu khmer patch It will be available in 7.4.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. |