Bug 119294 - Intermittent crash when Frame and document have blank database fields and "Hide paragraphs" option on
Summary: Intermittent crash when Frame and document have blank database fields and "Hi...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha0+ Master
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.2.0 target:6.1.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Mail-Merge
  Show dependency treegraph
 
Reported: 2018-08-15 12:05 UTC by Dom Walden
Modified: 2018-08-22 16:37 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Database file for reproduction (8.20 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-08-15 12:05 UTC, Dom Walden
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dom Walden 2018-08-15 12:05:45 UTC
Created attachment 144192 [details]
Database file for reproduction

_Description_

If I have a Frame which contains a database field and on the same line as the Frame another database field, if both database fields are blank then I will occasionally see a crash (about 1 in 3 times) when doing "Edit Individual Documents".

Only happens when "Hide paragraphs of database fields (e.g., mail merge) with an
empty value" is on.

I have not tried to see if this happens when doing Save or Print Merged Documents or Send E-Mail Messages.

Crash report: http://crashreport.libreoffice.org/stats/crash_details/b1a0a856-65e0-4a98-aac8-971aaceba566

_Steps to Reproduce_

Make sure you have Tools > Options > LibreOffice Writer >
Compatibility > "Hide paragraphs of database fields (e.g., mail merge) with an
empty value" option ticked.

1. Create a new Writer document
2. Insert > Frame > Frame..., click OK
3. Click inside the frame (to get a text cursor; may need to unfocus the frame first)
4. Insert > Field > More Fields...
5. Click the tab "Database" and under Type select "Mail merge fields"
6. Next to "Add database file" click "Browse..." and select the attached database file
7. From the Database selection select mailing_list_minimal > Sheet1 > Last Name
8. Click Insert
9. Without closing the dialog click outside of the frame, to return to cursor to the top of the page
10. Click Insert again and click Close
11. Add a new paragraph after the db field inserted in step 10, by pressing Enter key
12. Click View > Toolbars > Mail Merge
13. In the new toolbar click "Edit Individual Documents"

May need to repeat step 13 a few times. So far for me it happens within 3 goes.

_Actual Results_

LibreOffice exits.

_Expected Results_

LibreOffice shows the individual mail merge documents.


Reproducible: Intermittent

User Profile Reset: Yes


_Additional Info_
Version: 6.2.0.0.alpha0+
Build ID: 032c3f0d8403c6c7cdc60564641687bfb56cf9b3
CPU threads: 2; OS: Linux 3.16; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-08-14_22:24:06
Locale: en-GB (en_GB.UTF-8); Calc: threaded

I could not reproduce on 6.1RC2.
Comment 1 Mike Kaganski 2018-08-15 12:44:43 UTC Comment hidden (obsolete)
Comment 2 Mike Kaganski 2018-08-15 12:46:07 UTC
Sorry - I see that you are testing with an up-to-date master. Need to look at this.
Comment 3 Mike Kaganski 2018-08-15 19:19:33 UTC
The problem here is about trying to remove a node (frame) after its parent node (with its anchor) was already removed, which has removed the frame.
Comment 4 Xisco Faulí 2018-08-16 08:05:06 UTC
Just for the record, this is a regression from https://cgit.freedesktop.org/libreoffice/core/commit/?id=576fac6f6199a87fb07e4a067abaa18c89b6d7ea
Comment 5 Mike Kaganski 2018-08-16 08:49:58 UTC
Strictly speaking, I don't think this to be a regression from the commit mentioned in comment 4. That commit had rearranged the order in which the nodes removal happens, and now *this* document creation sequence triggers this problem; previously, another order of paragraph/frame/field creation could produce the same... this all is a regression from the first commit introducing the hiding behaviour.
Comment 6 Mike Kaganski 2018-08-16 11:06:07 UTC
https://gerrit.libreoffice.org/59164
Comment 7 Commit Notification 2018-08-16 13:07:25 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c883d5e073d2ac5b2d55126c929d7bf3e6d295e8

tdf#119294: reimplement fix for tdf#118859

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Mike Kaganski 2018-08-16 13:08:26 UTC
Backport to 6-1: https://gerrit.libreoffice.org/59175
Comment 9 Xisco Faulí 2018-08-20 16:41:15 UTC
Verified in

Version: 6.2.0.0.alpha0+
Build ID: 401cba4c20fbc930f034168872642428d7459218
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded

@Mike Kaganski, thanks for fixing this!
Comment 10 Commit Notification 2018-08-22 16:37:44 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b14bc12eee887b8a892f2bb114ffd50448a74d74&h=libreoffice-6-1

tdf#119294: reimplement fix for tdf#118859

It will be available in 6.1.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.