Bug 137592 - FILEOPEN: Crash when update section-links
Summary: FILEOPEN: Crash when update section-links
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace
Depends on:
Blocks: Section File-Opening
  Show dependency treegraph
 
Reported: 2020-10-19 12:01 UTC by Marco
Modified: 2021-04-15 15:37 UTC (History)
3 users (show)

See Also:
Crash report or crash signature: ["swlo.dll"]


Attachments
Pics about linked and nested sections (14.60 KB, application/x-zip-compressed)
2020-10-19 12:01 UTC, Marco
Details
odt-file-fixture (270.31 KB, application/x-zip-compressed)
2020-10-22 08:49 UTC, Marco
Details
backtrace from assertion (16.40 KB, text/plain)
2020-10-26 23:11 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marco 2020-10-19 12:01:22 UTC
Created attachment 166504 [details]
Pics about linked and nested sections

This bug was filed from the crash reporting server and is br-74761b2f-2a82-4d36-a928-65f9c713c8fc.
=========================================

Crash on update of linked section F-Frostschutzentleerung.odt 
(see img Verknüpfungen aktualisieren.PNG)

The section tree (no conditions) looks like shown in Bereichebaum.jpg.

The file/section dependencies are:

affecteddocument.odt 
     ---> comp/control/variantA/F-Frostschutzentleerung.odt
          --->  comp/control/Funktionen.odt : F_FSE.Zweck
          --->  comp/cabinet/VarinatA/Aufbau.odt : A_SS.SeTU.Bes

It is remarkable that the whole section (i.e. with all child sections) is refreshed properly. After that the crash occurs.
Comment 1 Dieter 2020-10-21 11:21:05 UTC
Is it possible for you to add that document or to create a document as example?
=> NEEDINFO
Comment 2 Marco 2020-10-22 08:49:53 UTC
Created attachment 166615 [details]
odt-file-fixture

Open "\comp\control\variantA\AffectedDocument.odt" and update link to "F - Frostschutzentleerung.odt" to reproduce crasth
Comment 3 Marco 2020-10-22 08:53:16 UTC
Hi Dieter
Thanks for throwing an eye on it!
I added a file fixture stripped down to the 'esential'.
I hope it helps..
Comment 4 Dieter 2020-10-22 10:10:37 UTC
1. I've tried opening document "AffectedDocument.odt".
2. LO asks me "Would you like to change the document, and update all links to get the most recent data?"
3. Yes => Crash

Crashreport: https://crashreport.libreoffice.org/stats/crash_details/7527242f-9a91-477d-ab4c-38bb9e1fe889

Marco, I've changed status to NEW, although it might be not exactly the same, you've described.
Comment 5 Marco 2020-10-22 11:16:49 UTC
Thanks Dieter, I assume the behaviour affected (updating linked sections) is the same.
Comment 6 Terrence Enger 2020-10-26 23:11:27 UTC
Created attachment 166749 [details]
backtrace from assertion

The backtrace is from a local build of commit 5219c6bd (2020-10-24),
built and running on debian-buster.

The terminal message is (rewrapped):
    soffice.bin: 
    /home/terry/lo_hacking/git/libo6/sw/source/core/bastyp/bparr.cxx:84:
    BigPtrEntry* BigPtrArray::operator[](sal_uLong) const:
    Assertion `idx < m_nSize' failed.

I am setting O/S = All, adjusting summary for my taste, and addking
keyword haveBacktrace.
Comment 7 Terrence Enger 2020-10-26 23:45:11 UTC
Working on debian-buster I see a crash in bibisect-50max version
oldest, among others.  I am setting version 4.3.0.4 release.

In bibisect-43all, I get unhelpful results:
  - Version latest has a segfault.
  - Version oldest accumulated 7 CPU minutes before displaying the
    update-links dialog.  I cancelled it then.
Comment 8 Roman Kuznetsov 2021-04-14 19:39:41 UTC
no crash with opening AffectedDocument.odt in

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 77419c6f3aba1fd5b1660795923c22a39bdb1bad
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL

=>WFM
Comment 9 Terrence Enger 2021-04-15 15:37:27 UTC
From comment 8, I conclude that the assertion which I reported in
comment 6 is a different problem.  I have created bug 141705 for that
assertion.