Bug 145892 - Crash (failed assert) in DBGUTIL build when inserting a section from a WEBP
Summary: Crash (failed assert) in DBGUTIL build when inserting a section from a WEBP
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.3.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.4.0
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-25 16:00 UTC by Mike Kaganski
Modified: 2021-12-06 13:44 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
A WEBP image ( source: https://upload.wikimedia.org/wikipedia/commons/a/a1/Johnrogershousemay2020.webp ) (629.87 KB, image/webp)
2021-11-25 16:00 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2021-11-25 16:00:29 UTC
Created attachment 176504 [details]
A WEBP image ( source: https://upload.wikimedia.org/wikipedia/commons/a/a1/Johnrogershousemay2020.webp )

1. Download the attachment.
2. In a DBGUTIL master build, create a new text document.
3. Insert->Section; select [x] Link; [ Browse ] and select the WEBP image, then [ 
Insert ]

=> Debug Error!

Program: C:\lo\src\build\instdir\program\soffice.bin

abort() has been called

(Press Retry to debug the application)

Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: f234bea67195ee2b9c80ba0b4a18b4a81cf57cfb
CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: fr-FR (ru_RU); UI: en-US
Calc: CL

The call stack is:

> icuucd70.dll!icu_70::KhmerBreakEngine::divideUpDictionaryRange(UText * text, int rangeStart, int rangeEnd, icu_70::UVector32 & foundBreaks, UErrorCode & status) Line 1198	C++
> icuucd70.dll!icu_70::DictionaryBreakEngine::findBreaks(UText * text, int startPos, int endPos, icu_70::UVector32 & foundBreaks, UErrorCode & status) Line 83	C++
> icuucd70.dll!icu_70::RuleBasedBreakIterator::DictionaryCache::populateDictionary(int startPos, int endPos, int firstRuleStatus, int otherRuleStatus) Line 166	C++
> icuucd70.dll!icu_70::RuleBasedBreakIterator::BreakCache::populatePreceding(UErrorCode & status) Line 551	C++
> icuucd70.dll!icu_70::RuleBasedBreakIterator::BreakCache::previous(UErrorCode & status) Line 291	C++
> icuucd70.dll!icu_70::RuleBasedBreakIterator::BreakCache::preceding(int startPos, UErrorCode & status) Line 259	C++
> icuucd70.dll!icu_70::RuleBasedBreakIterator::preceding(int offset) Line 670	C++
> i18npoollo.dll!i18npool::BreakIterator_Unicode::getLineBreak(const rtl::OUString & Text, long nStartPos, const com::sun::star::lang::Locale & rLocale, long nMinBreakPos, const com::sun::star::i18n::LineBreakHyphenationOptions & hOptions, const com::sun::star::i18n::LineBreakUserOptions & __formal) Line 508	C++
> i18npoollo.dll!i18npool::BreakIteratorImpl::getLineBreak(const rtl::OUString & Text, long nStartPos, const com::sun::star::lang::Locale & rLocale, long nMinBreakPos, const com::sun::star::i18n::LineBreakHyphenationOptions & hOptions, const com::sun::star::i18n::LineBreakUserOptions & bOptions) Line 280	C++
> swlo.dll!SwTextGuess::Guess(const SwTextPortion & rPor, SwTextFormatInfo & rInf, const unsigned short nPorHeight) Line 409	C++
> swlo.dll!SwTextPortion::Format_(SwTextFormatInfo & rInf) Line 305	C++
> swlo.dll!SwTextPortion::Format(SwTextFormatInfo & rInf) Line 457	C++
> swlo.dll!SwTextFormatter::BuildPortions(SwTextFormatInfo & rInf) Line 552	C++
> swlo.dll!SwTextFormatter::FormatLine(o3tl::strong_int<long,Tag_TextFrameIndex> nStartPos) Line 1691	C++
> swlo.dll!SwTextFrame::FormatLine(SwTextFormatter & rLine, const bool bPrev) Line 1198	C++
> swlo.dll!SwTextFrame::Format_(SwTextFormatter & rLine, SwTextFormatInfo & rInf, const bool bAdjust) Line 1555	C++
> swlo.dll!SwTextFrame::Format_(OutputDevice * pRenderContext, SwParaPortion * pPara) Line 1729	C++
> swlo.dll!SwTextFrame::Format(OutputDevice * pRenderContext, const SwBorderAttrs * __formal) Line 1917	C++
> swlo.dll!SwContentFrame::MakeAll(OutputDevice * __formal) Line 1515	C++
> swlo.dll!SwFrame::OptPrepareMake() Line 399	C++
> swlo.dll!SwFrame::OptCalc() Line 1087	C++
> swlo.dll!SwLayAction::FormatContent_(const SwContentFrame * pContent, const SwPageFrame * pPage) Line 1873	C++
> swlo.dll!SwLayAction::FormatContent(SwPageFrame * pPage) Line 1701	C++
> swlo.dll!SwLayAction::InternalAction(OutputDevice * pRenderContext) Line 587	C++
> swlo.dll!SwLayAction::Action(OutputDevice * pRenderContext) Line 386	C++
> swlo.dll!SwViewShell::ImplEndAction(const bool bIdleEnd) Line 289	C++
> swlo.dll!SwViewShell::EndAction(const bool bIdleEnd) Line 600	C++
> swlo.dll!SwCursorShell::EndAction(const bool bIdleEnd) Line 265	C++
> swlo.dll!SwEditShell::EndAllAction() Line 102	C++
> swlo.dll!SwEditShell::InsertSection(SwSectionData & rNewData, const SfxItemSet * const pAttr) Line 55	C++
> swuilo.dll!SwInsertSectionTabDialog::Ok() Line 1410	C++
> sfxlo.dll!SfxTabDialogController::OkHdl(weld::Button & __formal) Line 372	C++
> sfxlo.dll!SfxTabDialogController::LinkStubOkHdl(void * instance, weld::Button & data) Line 360	C++
> vcllo.dll!Link<weld::Button &,void>::Call(weld::Button & data) Line 111	C++
> vcllo.dll!weld::Button::signal_clicked() Line 1406	C++
> vcllo.dll!SalInstanceButton::ClickHdl(Button * pButton) Line 2663	C++
> vcllo.dll!SalInstanceButton::LinkStubClickHdl(void * instance, Button * data) Line 2650	C++
> vcllo.dll!Link<Button *,void>::Call(Button * data) Line 111	C++
> vcllo.dll!Button::Click::__l2::<lambda>() Line 130	C++
> vcllo.dll!std::invoke<void <lambda>(void) &>(Button::Click::__l2::void <lambda>(void) & _Obj) Line 1481	C++
> vcllo.dll!std::_Invoker_ret<void,1>::_Call<void <lambda>(void) &>(Button::Click::__l2::void <lambda>(void) & _Func) Line 665	C++
> vcllo.dll!std::_Func_impl_no_alloc<void <lambda>(void),void>::_Do_call() Line 836	C++
> vcllo.dll!std::_Func_class<void>::operator()() Line 883	C++
> vcllo.dll!Control::ImplCallEventListenersAndHandler(VclEventId nEvent, const std::function<void __cdecl(void)> & callHandler) Line 313	C++
> vcllo.dll!Button::Click() Line 130	C++
> vcllo.dll!PushButton::Tracking(const TrackingEvent & rTEvt) Line 1255	C++
> vcllo.dll!vcl::Window::EndTracking(TrackingEventFlags nFlags) Line 310	C++
> vcllo.dll!ImplHandleMouseEvent(const VclPtr<vcl::Window> & xWindow, MouseNotifyEvent nSVEvent, bool bMouseLeave, __int64 nX, __int64 nY, unsigned __int64 nMsgTime, unsigned short nCode, MouseEventModifiers nMode) Line 699	C++
> vcllo.dll!ImplHandleSalMouseButtonUp(vcl::Window * pWindow, const SalMouseEvent * pEvent) Line 2080	C++
> vcllo.dll!ImplWindowFrameProc(vcl::Window * _pWindow, SalEvent nEvent, const void * pEvent) Line 2435	C++
> vcllo.dll!SalFrame::CallCallback(SalEvent nEvent, const void * pEvent) Line 308	C++
> vclplug_winlo.dll!ImplHandleMouseMsg(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 3163	C++
> vclplug_winlo.dll!SalFrameWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam, bool & rDef) Line 5535	C++
> vclplug_winlo.dll!SalFrameWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 5888	C++
> user32.dll!00007ffc335ce7e8()	Unknown
> user32.dll!00007ffc335ce229()	Unknown
> vclplug_winlo.dll!ImplSalDispatchMessage(const tagMSG * pMsg) Line 416	C++
> vclplug_winlo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 493	C++
> vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 522	C++
> vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents) Line 465	C++
> vcllo.dll!Application::Yield() Line 533	C++
> vcllo.dll!Application::Execute() Line 444	C++
> sofficeapp.dll!desktop::Desktop::Main() Line 1601	C++
> vcllo.dll!ImplSVMain() Line 199	C++
> vcllo.dll!SVMain() Line 232	C++
> sofficeapp.dll!soffice_main() Line 98	C++
> soffice.bin!sal_main() Line 49	C
> soffice.bin!main(int argc, char * * argv) Line 47	C
> soffice.bin!invoke_main() Line 79	C++
> soffice.bin!__scrt_common_main_seh() Line 288	C++
> soffice.bin!__scrt_common_main() Line 331	C++
> soffice.bin!mainCRTStartup(void * __formal) Line 17	C++
> kernel32.dll!00007ffc337f7034()	Unknown
> ntdll.dll!00007ffc33b42651()	Unknown

Since it's ICU, maybe erAck has an idea what is wrong? (Yes I know that WEBP is not a plain text file, as LibreOffice treats it; but it must not crash it, right? For the record: I came across it while debugging tdf#145875, which shows insert section dialog in strange cases.)
Comment 1 Eike Rathke 2021-11-26 19:15:32 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.
Comment 2 Eike Rathke 2021-11-29 17:57:38 UTC
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.
Comment 3 Mike Kaganski 2021-11-30 11:03:12 UTC
(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)?
Comment 4 Caolán McNamara 2021-12-06 09:10:16 UTC
I see it under windows with ICU 69 so its not new with the upgrade AFAICS
Comment 5 Caolán McNamara 2021-12-06 10:54:49 UTC
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.
Comment 6 Caolán McNamara 2021-12-06 12:04:04 UTC
lets just disable the assert for dbgutil, it does eventually layout for me with no ill effect.
Comment 7 Commit Notification 2021-12-06 13:34:22 UTC
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.