Bug 158255 - Fatal exception: Signal 6 when opening or converting prior working document ( SwSectionFrame::Notify() )
Summary: Fatal exception: Signal 6 when opening or converting prior working document (...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.3.0.0.alpha1+
Hardware: All All
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Section
  Show dependency treegraph
 
Reported: 2023-11-17 15:23 UTC by Wahrendorff
Modified: 2023-12-06 11:06 UTC (History)
5 users (show)

See Also:
Crash report or crash signature: ["SwSectionFrame::Notify(SfxHint%20const%20&)"]


Attachments
generated odt file that crashes libreoffice (18.57 KB, application/vnd.oasis.opendocument.text)
2023-11-17 15:23 UTC, Wahrendorff
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wahrendorff 2023-11-17 15:23:33 UTC
Created attachment 190892 [details]
generated odt file that crashes libreoffice

Using libreoffice via UNO API to create pdf files and the like with odt as templates. 

We heavily use hidden sections and our own implementation of placeholders in the content.xml to dynamically change the content of the files.

Since Libreoffice 7.3 we get Fatal exception: Signal 6 from libreoffice when trying to open some manipulated odt files to convert to pdf.

We suspect the content size of the hidden sections could be somehow related, since this only happens with document templates having quite large hidden sections.

Attached a Document that causes the Fatal Exception on gui opening or converting via console. There is a possibility that we are causing the problem by manipulating the odt files context.xml and styles.xml before passing it to libreoffice via uno, but I cannot see anything problematic in the files content.xml and styles.xml and it is also working with older libreoffice versions. 

Our Windows Users say it broke with Libreoffice 7.4 and still working with Version 7.3 and Linux Users say it's already broke in Version 7.3, so I guess the error occured somewhere between 7.3.1.3 and 7.3.7.2

Stacktrace of error:
Unspecified Application Error


Fatal exception: Signal 6
Stack:
/usr/lib/libreoffice/program/libuno_sal.so.3(+0x41993)[0x7f53a93ab993]
/usr/lib/libreoffice/program/libuno_sal.so.3(+0x41b54)[0x7f53a93abb54]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f53a3e42520]
/lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0x12c)[0x7f53a3e969fc]
/lib/x86_64-linux-gnu/libc.so.6(raise+0x16)[0x7f53a3e42476]
/lib/x86_64-linux-gnu/libc.so.6(abort+0xd3)[0x7f53a3e287f3]
/usr/lib/libreoffice/program/libmergedlo.so(+0x12507d0)[0x7f53a54507d0]
/usr/lib/libreoffice/program/libmergedlo.so(+0x24b6126)[0x7f53a66b6126]
/usr/lib/libreoffice/program/libmergedlo.so(+0x36dedc7)[0x7f53a78dedc7]
/usr/lib/libreoffice/program/libuno_sal.so.3(+0x19962)[0x7f53a9383962]
/usr/lib/libreoffice/program/libuno_sal.so.3(+0x41a97)[0x7f53a93aba97]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f53a3e42520]
/usr/lib/libreoffice/program/libswlo.so(+0x7e1a82)[0x7f5396de1a82]
/usr/lib/libreoffice/program/libmergedlo.so(_ZN14SvtBroadcaster9BroadcastERK7SfxHint+0xec)[0x7f53a6806dec]
/usr/lib/libreoffice/program/libswlo.so(+0x66e4bb)[0x7f5396c6e4bb]
/usr/lib/libreoffice/program/libswlo.so(+0x5dbf05)[0x7f5396bdbf05]
/usr/lib/libreoffice/program/libswlo.so(+0x5dd33e)[0x7f5396bdd33e]
/usr/lib/libreoffice/program/libswlo.so(+0x5dd47c)[0x7f5396bdd47c]
/usr/lib/libreoffice/program/libswlo.so(_ZN11SwViewShell12UpdateFieldsEb+0x73)[0x7f539716b613]
/usr/lib/libreoffice/program/libswlo.so(_ZN15SwXTextDocument16getRendererCountERKN3com3sun4star3uno3AnyERKNS3_8SequenceINS2_5beans13PropertyValueEEE+0x92f)[0x7f53975163bf]
/usr/lib/libreoffice/program/libpdffilterlo.so(+0x34215)[0x7f5394aab215]
/usr/lib/libreoffice/program/libpdffilterlo.so(+0x3c776)[0x7f5394ab3776]
/usr/lib/libreoffice/program/libpdffilterlo.so(+0x3ddb0)[0x7f5394ab4db0]
/usr/lib/libreoffice/program/libmergedlo.so(_ZN14SfxObjectShell8ExportToER9SfxMedium+0x8ea)[0x7f53a6595fca]
/usr/lib/libreoffice/program/libmergedlo.so(+0x239ddbb)[0x7f53a659ddbb]
/usr/lib/libreoffice/program/libmergedlo.so(+0x23a0329)[0x7f53a65a0329]
/usr/lib/libreoffice/program/libmergedlo.so(+0x23a16f0)[0x7f53a65a16f0]
/usr/lib/libreoffice/program/libmergedlo.so(+0x2380442)[0x7f53a6580442]
/usr/lib/libreoffice/program/libmergedlo.so(+0x23d07ba)[0x7f53a65d07ba]
/usr/lib/libreoffice/program/libmergedlo.so(_ZN12SfxBaseModel10storeToURLERKN3rtl8OUStringERKN3com3sun4star3uno8SequenceINS6_5beans13PropertyValueEEE+0x265)[0x7f53a65d2555]
/usr/lib/libreoffice/program/libmergedlo.so(+0x24d22ab)[0x7f53a66d22ab]
/usr/lib/libreoffice/program/libmergedlo.so(+0x24d5e46)[0x7f53a66d5e46]
/usr/lib/libreoffice/program/libmergedlo.so(+0x24b86a3)[0x7f53a66b86a3]
/usr/lib/libreoffice/program/libmergedlo.so(+0x24b9bad)[0x7f53a66b9bad]
/usr/lib/libreoffice/program/libmergedlo.so(+0x33d9bf8)[0x7f53a75d9bf8]
/usr/lib/libreoffice/program/libmergedlo.so(_ZN14SvpSalInstance12ProcessEventEN16SalUserEventList12SalUserEventE+0x2c)[0x7f53a7a7627c]
/usr/lib/libreoffice/program/libmergedlo.so(_ZN16SalUserEventList18DispatchUserEventsEb+0x142)[0x7f53a788d602]
/usr/lib/libreoffice/program/libmergedlo.so(_ZN14SvpSalInstance9ImplYieldEbb+0x36)[0x7f53a7a768a6]
/usr/lib/libreoffice/program/libmergedlo.so(_ZN14SvpSalInstance7DoYieldEbb+0x17d)[0x7f53a7a76cfd]
/usr/lib/libreoffice/program/libmergedlo.so(+0x36d4fd2)[0x7f53a78d4fd2]
/usr/lib/libreoffice/program/libmergedlo.so(_ZN11Application7ExecuteEv+0x65)[0x7f53a78d5955]
/usr/lib/libreoffice/program/libmergedlo.so(+0x24bc5dd)[0x7f53a66bc5dd]
/usr/lib/libreoffice/program/libmergedlo.so(_Z10ImplSVMainv+0x51)[0x7f53a78e05a1]
/usr/lib/libreoffice/program/libmergedlo.so(soffice_main+0x9e)[0x7f53a66db0be]
/usr/lib/libreoffice/program/soffice.bin(+0x10b0)[0x563089bb20b0]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f53a3e29d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f53a3e29e40]
/usr/lib/libreoffice/program/soffice.bin(+0x10e5)[0x563089bb20e5]
Comment 1 Wahrendorff 2023-11-17 15:47:16 UTC
Correction: I got a notice that he error occures only on linux, not on windows.
Comment 2 m_a_riosv 2023-11-17 16:04:50 UTC
It appears that the file does not pass the validator, regardless of the version selected for testing.
https://odfvalidator.org/
Comment 3 Eike Rathke 2023-11-17 17:05:44 UTC
Apart from that the mimetype file in the zip container is compressed which it must not (see ODF specification), and the unexpected attribute "text:is-hidden" the validator complains about (only those two errors with extended conformant ODF1.3), the crash is a nullptr dereference in sw/source/core/layout/sectfrm.cxx SwSectionFrame::Notify() where in

SwSectionFormat *const pFormat(GetSection()->GetFormat());

the GetSection() call returns nullptr.

My blind guess is it there should check for nullptr and bail out if so, but I'm not familiar with that code and maybe it's just a symptom and not the cause.
Comment 4 Wahrendorff 2023-11-22 10:14:36 UTC
(In reply to m.a.riosv from comment #2)
> It appears that the file does not pass the validator, regardless of the
> version selected for testing.
> https://odfvalidator.org/

I just validated some random documents that have been created with Libreoffice over the past years and not manipulated by any other entity: They all seem to not pass the Validator because of unknown tags or unexpected attributes, but they do not crash libreoffice 7 upon PDF generating.

(In reply to Eike Rathke from comment #3)
> Apart from that the mimetype file in the zip container is compressed which
> it must not (see ODF specification), and the unexpected attribute
> "text:is-hidden" the validator complains about (only those two errors with
> extended conformant ODF1.3), the crash is a nullptr dereference in
> sw/source/core/layout/sectfrm.cxx SwSectionFrame::Notify() where in
> 
> SwSectionFormat *const pFormat(GetSection()->GetFormat());
> 
> the GetSection() call returns nullptr.
> 
> My blind guess is it there should check for nullptr and bail out if so, but
> I'm not familiar with that code and maybe it's just a symptom and not the
> cause.

I managed to not compress the mimetype file, but it still crashes Libreoffice. 

Your suggestion sounds like a reasonable fix for me. It resonates with the behaviour that libreoffice will not crash, when all sections in the odt are initially visible and not hidden.
Comment 5 Buovjaga 2023-12-01 15:23:59 UTC
Used Tools - Update - Fields (F9).

Bibisected with linux-64-7.3 to b14f5424dde966fa3764a7e5c813dc727390354c
tdf#146605 sw: try to fix SwSectionFormat notifications

Crash upon opening started happening in 7.5 with c8e9df0b583e8a61a0570f72c0a476a5102f1fe9 "Always update fields when loading document"
Comment 6 Wahrendorff 2023-12-06 11:06:56 UTC
In addition: 
I played with the content.xml and found out removing the Attribute text:is-hidden="true" on text:section with name "~#1_0_FR" does not crash the file upon opening, while everything continues to work as expected.