Bug 150138 - FILEOPEN: Writer crashes when opening ODT file
Summary: FILEOPEN: Writer crashes when opening ODT file
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha1+
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.5.0 target:7.4.1
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks: Crash-Assert
  Show dependency treegraph
 
Reported: 2022-07-25 11:42 UTC by Kamil Landa
Modified: 2022-08-13 14:44 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
ODT with some tables and own arabic font (261.50 KB, application/vnd.oasis.opendocument.text)
2022-07-25 11:42 UTC, Kamil Landa
Details
bt with debug symbols (8.48 KB, text/plain)
2022-07-25 18:09 UTC, Julien Nabet
Details
Same file, but with "Amiri Quran" font (339.54 KB, application/vnd.oasis.opendocument.text)
2022-07-25 21:52 UTC, Hossein
Details
explanation for font arabicTest (919.35 KB, application/pdf)
2022-07-26 08:10 UTC, Kamil Landa
Details
no crash with the dot at start of lines (261.67 KB, application/vnd.oasis.opendocument.text)
2022-07-27 14:01 UTC, Kamil Landa
Details
bt with debug symbols (7.21 KB, text/plain)
2022-08-13 12:33 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kamil Landa 2022-07-25 11:42:03 UTC
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
Comment 1 m_a_riosv 2022-07-25 14:32:09 UTC
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/
Comment 2 raal 2022-07-25 15:24:43 UTC
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
Comment 3 Julien Nabet 2022-07-25 18:09:10 UTC
Created attachment 181406 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today I got an assertion.
Comment 4 Hossein 2022-07-25 18:38:54 UTC
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
Comment 5 Hossein 2022-07-25 21:49:06 UTC
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.
Comment 6 Hossein 2022-07-25 21:52:07 UTC
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.
Comment 7 Kamil Landa 2022-07-26 08:10:46 UTC
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.
Comment 8 Kamil Landa 2022-07-27 14:01:38 UTC
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
Comment 9 Commit Notification 2022-08-12 10:14:06 UTC
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.
Comment 10 Caolán McNamara 2022-08-12 19:45:26 UTC
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
Comment 11 Kamil Landa 2022-08-13 10:36:20 UTC
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
Comment 12 Kamil Landa 2022-08-13 10:39:21 UTC
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
Comment 13 Julien Nabet 2022-08-13 12:33:36 UTC
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.
Comment 14 Commit Notification 2022-08-13 14:44:36 UTC
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.