Created attachment 181402 [details] ODT with some tables and own arabic font Try to open attached ODT file and Writer will start to read file, but then it will crash. It seems there is some bad commit between versions 7.4.0.0.alpha0+ (OK) and 7.4.0.0.alpha1 (crash). Crash: Version: 7.4.0.1 (x64) / LibreOffice Community Build ID: 43e5fcfbbadd18fccee5a6f42ddd533e40151bcf CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL Version: 7.4.0.0.beta1 (x64) / LibreOffice Community Build ID: cec1fe9b57a55c032f9f118c907f34e22a63d040 CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL Version: 7.4.0.0.alpha1 (x64) / LibreOffice Community Build ID: b871abad383583f02eb49c7e49aeae01f6941072 CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL -------------------- But it is OK for example in older versions: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 151c56ed547490a99d912524c0e56b5d6d4a1939 CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL Version: 7.3.5.1 (x64) / LibreOffice Community Build ID: d56c1c78db15939340c3db8ee3b6667832313d23 CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL
Confirmed, open with Version: 7.3.5.2 (x64) / LibreOffice Community Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL Crash also with Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: eea7038c182cc1f6cd792359053ea2561a200026 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL The file doesn't pass the validation test. https://odfvalidator.org/
This seems to have begun at the below commit. Adding Cc: to Luboš Luňák; Could you possibly take a look at this one? Thanks 16d2c140047b718f2c49f3fd8991a28a6e347e60 is the first bad commit commit 16d2c140047b718f2c49f3fd8991a28a6e347e60 Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed May 11 19:39:17 2022 +0200 source 5caa7f44b861876afa5b3b8f71e3848abd8875e6 https://git.libreoffice.org/core/+/5caa7f44b861876afa5b3b8f71e3848abd8875e6
Created attachment 181406 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today I got an assertion.
Stack trace, created using Qt Creator: 1 __pthread_kill_implementation pthread_kill.c 44 0x7ffff79f4a7c 2 __pthread_kill_internal pthread_kill.c 78 0x7ffff79f4a7c 3 __GI___pthread_kill pthread_kill.c 89 0x7ffff79f4a7c 4 __GI_raise raise.c 26 0x7ffff79a0476 5 __GI_abort abort.c 79 0x7ffff79867f3 6 __assert_fail_base assert.c 92 0x7ffff798671b 7 __GI___assert_fail assert.c 101 0x7ffff7997e96 8 checkGlyphsEqual impglyphitem.cxx 342 0x7fffef0bafca 9 SalLayoutGlyphsCache::GetLayoutGlyphs impglyphitem.cxx 443 0x7fffef0bb94e 10 SwFont::GetTextBreak fntcache.cxx 2049 0x7fffacf21d69 11 SwTextSizeInfo::GetTextBreak inftxt.cxx 450 0x7fffacddfce7 12 SwTextGuess::Guess guess.cxx 271 0x7fffacdd94a7 13 SwTextPortion::Format_ portxt.cxx 305 0x7ffface67eac 14 SwTextPortion::Format portxt.cxx 462 0x7ffface68c80 15 SwTextFormatter::BuildPortions itrform2.cxx 561 0x7ffface052eb 16 SwTextFormatter::FormatLine itrform2.cxx 1734 0x7ffface0b04e 17 SwTextFrame::FormatLine frmform.cxx 1212 0x7fffacdca695 18 SwTextFrame::Format_ frmform.cxx 1572 0x7fffacdcbf7a 19 SwTextFrame::Format_ frmform.cxx 1762 0x7fffacdccaea 20 SwTextFrame::Format frmform.cxx 1951 0x7fffacdcd864 21 SwContentFrame::MakeAll calcmove.cxx 1514 0x7fffacbc88df 22 SwFrame::PrepareMake calcmove.cxx 375 0x7fffacbc316b 23 SwFrame::Calc trvlfrm.cxx 1806 0x7fffaccf780c 24 SwContentFrame::CalcLowers tabfrm.cxx 1552 0x7fffaccdefef 25 lcl_RecalcRow tabfrm.cxx 1687 0x7fffaccdf9f3 26 lcl_RecalcTable tabfrm.cxx 1745 0x7fffaccdff6b 27 SwTabFrame::MakeAll tabfrm.cxx 2386 0x7fffacce2405 28 SwFrame::PrepareMake calcmove.cxx 375 0x7fffacbc316b 29 SwFrame::Calc trvlfrm.cxx 1806 0x7fffaccf780c 30 SwFrame::PrepareMake calcmove.cxx 253 0x7fffacbc2a30 31 SwFrame::Calc trvlfrm.cxx 1806 0x7fffaccf780c 32 SwFrame::PrepareMake calcmove.cxx 253 0x7fffacbc2a30 33 SwFrame::Calc trvlfrm.cxx 1806 0x7fffaccf780c 34 SwFrame::OptPrepareMake calcmove.cxx 386 0x7fffacbc32be 35 SwFrame::OptCalc frame.hxx 1084 0x7fffacc33107 36 SwLayAction::FormatContent_ layact.cxx 1887 0x7fffacc30258 37 SwLayAction::FormatContent layact.cxx 1708 0x7fffacc2f4ec 38 SwLayAction::InternalAction layact.cxx 778 0x7fffacc2b169 39 SwLayAction::Action layact.cxx 388 0x7fffacc29cc5 40 SwLayIdle::SwLayIdle layact.cxx 2267 0x7fffacc32245 41 SwViewShell::LayoutIdle viewsh.cxx 821 0x7fffad308691 42 sw::DocumentTimerManager::DoIdleJobs DocumentTimerManager.cxx 176 0x7fffac7c2f34 43 sw::DocumentTimerManager::LinkStubDoIdleJobs DocumentTimerManager.cxx 156 0x7fffac7c2de5 44 Link<Timer *, void>::Call link.hxx 111 0x7fffef495cef 45 Timer::Invoke timer.cxx 75 0x7fffef495b5b 46 Scheduler::CallbackTaskScheduling scheduler.cxx 472 0x7fffef441f76 47 SalTimer::CallCallback saltimer.hxx 54 0x7fffe44dac3b 48 sal_gtk_timeout_dispatch gtkdata.cxx 733 0x7fffe44d9c5a 49 g_main_context_dispatch 0x7fffe953cc24 50 ?? 0x7fffe95916f8 51 g_main_context_iteration 0x7fffe953a3c3 52 GtkSalData::Yield gtkdata.cxx 405 0x7fffe44d8db8 53 GtkInstance::DoYield gtkinst.cxx 429 0x7fffe44ddc7c 54 ImplYield svapp.cxx 474 0x7fffef47220a 55 Application::Yield svapp.cxx 558 0x7fffef472eec 56 Application::Execute svapp.cxx 452 0x7fffef471eaa 57 desktop::Desktop::Main app.cxx 1600 0x7ffff7c099c6 58 ImplSVMain svmain.cxx 203 0x7fffef491bc1 59 SVMain svmain.cxx 235 0x7fffef491cea 60 soffice_main sofficemain.cxx 94 0x7ffff7c73b39 61 sal_main main.c 51 0x555555554a60 62 main main.c 49 0x555555554a42
The Arabic text inside the document has these characteristics: 1. It has several diacritical marks, which are sometimes put above each one excessively. 2. Tatweel character (ـ) is used extensively to extend the size of some words. 3. The font chosen for the characters is non-existent: "arabicTest". In this way, many glyphs are missing, even in the display from earlier versions that don't crash. 4. I have changed font of all the text to "Amiri Quran" with LO 7.3 which does not crash here. In this way, LibreOffice master does not crash on the new file.
Created attachment 181409 [details] Same file, but with "Amiri Quran" font I think fixing the problem with the fallback font can help here. LibreOffice master does not crash while opening this file which uses "Amiri Quran" font. This file is created with LibreOffice 7.3 which does not crash on the input file.
Created attachment 181415 [details] explanation for font arabicTest Yes, with other fonts it doesn't crash. But let me tell the explanation :-). I deleted the characters from font 'arabicTest', because it is my personal font but based on the 'KFGQPC Uthman Taha Naskh' that has the licence restrictions. 'Amiri Quran' hasn't characters with the extended widths of glyphs, but 'arabicTest' has. Problem with the different wides of arabic glyphs is still unsolved: https://bugs.documentfoundation.org/show_bug.cgi?id=104921 But I supposed there isn't needful to have all shapes of glyphs in the font to discover why the commit does a crash. But if it is needful, I think I could send full 'arabicTest' to the email, because I don't want to (and I'm not allowed to) publish it. Maybe I will never publish this font, because the goal is to create Tajweed SVG graphic for the Quran and not only a font. I make it nearly 6 years and I'm still not at the end, so next reason why I don't publish the font is, it isn't finished :-). I attach the example.
Created attachment 181440 [details] no crash with the dot at start of lines I made Find&Replace to have different characters at start of each line, so it put dots before the numbering. (F&R regex Find: ^(\d) Repl: .$1) And now the crash isn't. I also tested Hair Space (#200A) instead the dot, but it crashed. Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 41f02927b6d8470c298c8a2f407c98420a5ebe24 CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/82553b46b689c0ff4c218a2a70918c3f4dafccfe fix checking glyph break position (tdf#150138) It will be available in 7.5.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 I still see an assert like this with another document in crashtesting, to reproduce: wget https://bugs.documentfoundation.org/attachment.cgi?id=143959 -O ~/tdf119074-1.odt ./instdir/program/soffice --headless --convert-to pdf ~/tdf119074-1.odt
In reply to Commit Notification from comment #9 Confirmed, fixed in 7.5.0.0.alpha0+ Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: f4027dd967a3292cfba689ca735d839b16ac2d92 CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL
In reply to Caolán McNamara from comment #10 Cannot confirm the crash under Win10. Normally open with 7.4.0.2 and also with 7.5.0.0.alpha0. Normally converted to PDF from command line with 7.4.0.2. And with 7.5.0.0.alpha0 it is converted when I renamed the file for example to some standard english-ascii like aaa.odt. But there are some errors showed in command line but I think it is because under Windows there is some misapprehension between installed parallel versions like normal version and Dev version. Version: 7.4.0.2 (x64) / LibreOffice Community Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: f4027dd967a3292cfba689ca735d839b16ac2d92 CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL
Created attachment 181757 [details] bt with debug symbols Here's a bt of assertion I got on pc Debian x86-64 with master sources updated today just when opening the file and sliding a bit.
Luboš Luňák committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/7e428644ff93ecccda9196ebff8883f6f077c7b8 fix checking glyph break position (tdf#150138) It will be available in 7.4.1. 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.